DOC PREVIEW
Taking Transactions Mainstream

This preview shows page 1-2-23-24 out of 24 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 24 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 24 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 24 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 24 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 24 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Taking Transactions Mainstream: Social Failure Modes and RecoveryDisclaimersMicrosoft & Transactions To DateTransactional Mechanics 101Isolation and the Three PartiesThree Parties and PerformanceTransactional Mechanics 102Static vs. Dynamic EnlistmentThe App Server EraDeclarative TransactionsDeclarative Transactions in MTSTrouble in Paradise?Problem: Transaction ExtractionAvoiding Transaction ExtractionProblem: Transaction InjectionAvoiding Transaction InjectionThe Dangers of Suppressing PropagationTransactions and TrustTransactions and TimeCore Problem: CompositionLife After A TransactionTransactions and ResultsTransactions and Future WorkSo, Where are we?Taking Transactions Mainstream: Social Failure Modes and RecoveryDon Box, Microsoft CorpDisclaimers•This talk is mostly looking backwards–Future is way less clear than the past–Lots of interesting data to be harvested–STM may look more like the past than we think•Microsoft stack used in examples–It’s the one I know best–I’ll qualify where things are different–When in doubt, assume we have it worseMicrosoft & Transactions To DateTransactional Mechanics 101•Three Party System–Application – establishes transaction boundaries and initiates work–Resource Manager (RM) – performs transactional work on behalf of application–Transaction Manager (TM) – coordinates outcome with application and resource managers•Resource manager may be durable (survives crashes) or volatile (doesn’t)Isolation and the Three Parties•The Application specifies the desired isolation level when it asks the TM for new transaction•RMs discover isolation level from transaction at enlistment-time•RMs implement isolation however they see fit–May use two-phase locking–May use multi-versioning–May provide RM-specific overridesThree Parties and Performance•In the limit, every party is on a distinct box–Lots of marshaling and x-host communication•If there’s only one RM, no 2PC needed–TM delegates commit to RM•If all resources are volatile, TM needn’t log•If all resources are volatile and in-proc, 2PC reduces to virtcalls++Transactional Mechanics 102•Transactions protect operations on a managed resource•Some resource managers dynamically enlist with the transaction at the time of invocation–Op1(tx, args)–Op2(tx, args)•Some resource managers statically enlist a session with the transaction–Bind(conn, tx)–Op1(conn, args)–Op2(conn, args)Static vs. Dynamic Enlistment•Dynamic enlistment is what people expect–Transactions are temporal phenomena–Transactions “flow” with thread of control•Static enlistment was a performance optimization–Most early RMs were x-proc/x-host–Marshaling transactions non-trivial due to logging•Matters get worse when transactions are passed implicitly–Does op use cached tx, current tx, or no tx?–State of the practice is RTFMThe App Server Era•1996-2006+: App Server era–OLTP + Distributed Objects + the Web•Microsoft: MTS + DCOM + IIS/ASP•Sun et al: EJB + RMI + Servlets/JSP•Emblematic features–Declarative Transactions–Managed execution/deployment environment–N-tier design style (transaction composition)Declarative Transactions•Captured transactional requirements as data•The “system” guaranteed that your code ran with an implicit transaction (typically in TLS)•Your implicit transaction propagated to other chunks of code you called by default•Your code gets to influence transaction outcome via implicit contextDeclarative Transactions in MTSint MyMethod(string name) { GetObjectContext().SetAbort(); int id = CreateUser(name); AuditChange(id, name + " was added"); GetObjectContext().SetComplete(); return id;}Class MyClass Transaction=RequiredTrouble in Paradise?•Previous example shows the ideal–Declaration of intent visible to system–Work composes without manual transaction enlistment or propagation–Most important: Code knows its transactional•Potential Problem #1: Transaction Extraction•Potential Problem #2: Transaction InjectionProblem: Transaction Extraction•Developer writes code with expectations of atomicity•Declaration captures this expectation•At least one system allows admin to change declaration without developer consent•It took us years to fix this–ASP got it right from day one Avoiding Transaction Extraction•Obvious Solution: Embed it with (or in) codeint MyMethod(string name) { int id = 0; using (TransactionScope scope = new TransationScope()) { id = CreateUser(name); AuditChange(id, name + " was added"); scope.Complete(); } return id;}[OperationBehavior(TransactionScopeRequired=true)]int MyMethod(string name) { int id = CreateUser(name); AuditChange(id, name + " was added"); return id;}Problem: Transaction Injection•Transaction Injection problem way more insidious (and harder to fix)•Transaction-ignorant code tends to:–Interact with non-transactional resources–Interact with transactional resources–Cache connections to static-binding RMs–Interact with userAvoiding Transaction Injection•If you know about transactions, you can turn them off (or at least suppress propagation)int MyMethod(string name) { int id = 0; using (TransactionScope scope = new TransationScope(TransactionScopeOption.RequiresNew)) { id = CreateUser(name); AuditChange(id, name + " was added"); scope.Complete(); } return id;}The Dangers of Suppressing Propagation•Previous example forced itself into a transaction that was distinct from its caller’s–Two independent outcomes (by design)–These are not nested transactions (by design)•If caller and callee access a common resource, we have an isolation problem–Will likely tank one of the transactions due to timeout (deadlock) or validation errorTransactions and Trust•Previous example demonstrated one side of composition problem (callee distrusts caller)•Problem also applies in reverse direction–Passing transaction to callee gives ability to rollback (feature and bug)–Passing transaction to callee gives ability to significantly increase transaction time–The latter flies in the face of TX dogmaTransactions and Time•Transaction isolation discourages long-running transactions–Two-phase locking leads to blocking/starvation–Multi-versioning leads to rollbacks from validation failures–Neither of these an issue with private resources•Unfortunately, we’re still screwed due to heterogeneity–No central lock


Taking Transactions Mainstream

Download Taking Transactions Mainstream
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Taking Transactions Mainstream and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Taking Transactions Mainstream 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?