Distributed Systems 12. Distributed Transactions Paul Krzyzanowski [email protected] 10/24/12 © 2012 Paul Krzyzanowski 1Atomic Transactions • Transaction – An operation composed of a number of discrete steps. • All the steps must be completed for the transaction to be committed. The results are made permanent. • Otherwise, the transaction is aborted and the state of the system reverts to what it was before the transaction started. 10/24/12 © 2012 Paul Krzyzanowski 2Example • Buying a house: – Make an offer – Sign contract – Deposit money in escrow – Inspect the house – Critical problems from inspection? – Get a mortgage – Have seller make repairs – Commit: sign closing papers & transfer deed – Abort: return escrow and revert to pre-purchase stat All or nothing property 10/24/12 © 2012 Paul Krzyzanowski 3Basic Operations • Transaction primitives: – Begin transaction: mark the start of a transaction – End transaction: mark the end of a transaction; try to commit – Abort transaction: kill the transaction, restore old values – Read/write data from files (or object stores): data will have to be restored if the transaction is aborted. 10/24/12 © 2012 Paul Krzyzanowski 4Another Example Book a flight from Newark, New Jersey to Inyokern, California. No non-stop flights are available: Transaction begin 1. Reserve a seat for Newark to Denver (EWR→DEN) 2. Reserve a seat for Denver to Los Angeles (DEN→LAX) 3. Reserve a seat for Denver to Inyokern (LAX→IYK) Transaction end If there are no seats available on the LAX→IYK leg of the journey, the transaction is aborted and reservations for (1) and (2) are undone. 10/24/12 © 2012 Paul Krzyzanowski 5Properties of transactions: ACID • Atomic – The transaction happens as a single indivisible action. Everything succeeds or else the entire transaction is rolled back. Others do not see intermediate results. • Consistent – A transaction cannot leave the database in an inconsistent state. If the system has invariants, they must hold after the transaction. E.g., total amount of money in all accounts must be the same before and after a “transfer funds” transaction. • Isolated (Serializable) – Transactions cannot interfere with each other If transactions run at the same time, the final result must be the same as if they executed in some serial order. • Durable – Once a transaction commits, the results are made permanent. No failures after a commit will cause the results to revert. 10/24/12 © 2012 Paul Krzyzanowski 6Nested Transactions • A top-level transaction may create subtransactions • Problem: – subtransactions may commit (results are durable) but the parent transaction may abort. • One solution: private workspace – Each subtransaction is given a private copy of every object it manipulates. On commit, the private copy displaces the parent’s copy (which may also be a private copy of the parent’s parent) 10/24/12 © 2012 Paul Krzyzanowski 7Implementing a private workspace [PLAN A] • Consider a Unix-like file system: – duplicate the file’s index (i-node) – Create new block when it gets modified by the transaction: shadow block – Index copy points to the shadow block • On abort: remove shadow blocks and private index • On commit: update parent’s index with private index attributes →Block 329 →Block 251 →Block 783 →Block 696 myfile Block 329 Block 251 Block 783 Block 696 attributes →Block 329 →Block 933 →Block 783 →Block 936 myfile’ Block 933 Block 936 10/24/12 © 2012 Paul Krzyzanowski 8Implementing a private workspace [PLAN B] • Use a writeahead log (intentions list) – Keep a log in stable storage – Before making any changes to the object, write a record to the log identifying { transaction ID, object ID, old value, new value } – If transaction commits: • Write a commit record onto the log – If transaction aborts • Use log to back up to the original state: rollback • Stable storage: data persists even if the system or application crashes. 10/24/12 © 2012 Paul Krzyzanowski 9Distributed Transactions • Transaction that updates data on two or more systems • Challenge – Handle machine, software, & network failures while preserving transaction integrity 10/24/12 © 2012 Paul Krzyzanowski 10Transaction States working prepared (done) committed aborted When a cohort enters the prepared state, it contacts the coordinator to start the commit protocol to commit the entire transaction started 10/24/12 © 2012 Paul Krzyzanowski 11Distributed Transactions • Each computer runs a transaction manager – Responsible for subtransactions on that system – Transaction managers communicate with other transaction managers – Performs prepare, commit, and abort calls for subtransactions • Each subtransaction must agree to commit changes before the transaction can complete 10/24/12 © 2012 Paul Krzyzanowski 12Two-phase commit protocol Goal: Reliably agree to commit or abort a collection of sub-transactions • All processes in the transaction will agree to commit or abort • One transaction manager is elected as a coordinator – the rest are cohorts • Assume: – write-ahead log in stable storage – No system dies forever – Systems can always communicate with each other 10/24/12 © 2012 Paul Krzyzanowski 13Two-Phase Commit Protocol: Phase 1 Get distributed agreement: the coordinator asked each cohort if it will commit or abort and received replies from each coordinator. Coordinator Cohort • Write prepare to commit to log • Work on transaction • Send prepare to commit message • Wait for message from coordinator • Wait for all cohorts to respond • When ready, write agree to commit or abort to the log Voting Phase • Receive the prepare message • Send agree to commit or abort to the the coordinator 10/24/12 © 2012 Paul Krzyzanowski 14Two-Phase Commit Protocol: Phase 2 Either ask all cohorts to commit or abort Get everyone’s response that they’re done. Coordinator Cohort • Write commit or abort to log • Wait for commit/abort message • Send commit or abort • Receive commit or abort • Wait for all cohorts to respond • If a commit