Computer Science 328 Distributed Systems

1. Computer Science 328Distributed Systems Lecture 10 Transaction Processing

2. Transactions • Sequences of operations that forms a single step, transforming the server data from one consistent state to another. • All or nothing principle: a transaction either completes successfully, and the effects are recorded in the objects, or it has no effect at all. • Transactions’ operations are indivisible from the point of view of other transactions • No access to intermediate results/states • Free from interference by other operations • Transactions may be distributed • Transactions could run concurrently

3. Example Transaction Banking transaction for a customer (ATM) Transfer $100 from saving to checking account; Transfer $200 from money-market to checking account; Withdraw $400 from checking account. Transaction: 1. savings.deduct(100) /* includes verification */ 2. checking.add(100) /* depends on success of 1 */ 3. mnymkt.deduct(200) /* includes verification */ 4. checking.add(200) /* depends on success of 3 */ 5. checking.deduct(400) /* includes verification */ 6. commit 7. dispense(400)

4. Transaction Failure Modes A failure at these points does not cause lost money, but the transaction cannot be repeated A failure at these points means the customer looses money, we need to restore Transaction: 1. savings.deduct(100) 2. checking.add(100) 3. mnymkt.deduct(200) 4. checking.add(200) 5. checking.deduct(400) 6. commit 7. dispense(400) A failure after the commit point (ATM crashes) needs corrective action, no undoing possible. This is the point of no return

5. Properties of Transactions (ACID) • Atomicity: All or nothing • Consistency: starting in a consistent state, the transaction ends in a consistent state. • Isolation: Each transaction must be performed without interference from other transactions, i.e., the intermediate effects of a transaction must not be visible to other transactions. • Durability: After a transaction has completed successfully, all its effects are saved in permanent storage. • Data saved in a file will survive if the server process crashes. “To support failure atomicity and durability, objects must be recoverable”

6. Operations in Coordinator Interface • Transactions are managed by a coordinator: • openTransaction() -> trans; • starts a new transaction and delivers a unique TID trans. This identifier will be used in the other operations in the transaction. • closeTransaction(trans) -> (commit, abort); • ends a transaction: a commit return value indicates that the transaction has committed; an abort return value indicates that it has aborted. • abortTransaction(trans); • aborts the transaction. • TID can be passed implicitly with RMI • Transactions are achieved by cooperation between client program, the coordinator, and recoverable objects.

7. Operations of the Account interface Operations of the Account interface • deposit(amount) • deposit amount in the account • withdraw(amount) • withdraw amount from the account • getBalance() -> amount • return the balance of the account • setBalance(amount) • set the balance of the account to amount Operations of the Branch interface • create(name) -> account • create a new account with a given name • lookUp(name) -> account • return a reference to the account with the given name • branchTotal() -> amount • return the total of all the balances at the branch

8. Concurrency Control: Lost Update 200 300 100 b: c: a: • One transaction causes loss of info. for another: consider three account objects Transaction T1 Transaction T2 balance = b.getBalance() balance = b.getBalance() b.setBalance(balance*1.1) b.setBalance = (balance*1.1) a.withdraw(balance* 0.1) c.withdraw(balance*0.1) T2’s update on the shared object, “b” is lost 220 b: 220 b: 80 a: 280 c:

9. Concurrency Control: Inconsistent Retrieval 200 300 100 b: c: a: • Partial, incomplete results of one transaction are retrieved by another transaction. Transaction T1 Transaction T2 a.withdraw(100) total = a.getBalance() total = total + b.getBalance b.deposit(100) total = total + c.getBalance T1’s partial result is used by T2, giving the wrong result 00 a: total 0.00 200 300 b: 500

10. Serial Equivalence • An interleaving of the operations of 2 or more transactions is said to be serially equivalent if the combined effect is the same as if these transactions had been performed sequentially. Transaction T1 Transaction T2 balance = b.getBalance() b.setBalance = (balance*1.1) balance = b.getBalance() b.setBalance(balance*1.1) a.withdraw(balance* 0.1) c.withdraw(balance*0.1) 200 300 100 b: c: a: 220 b: 242 b: 80 a: 278 c:

11. Conflicting Operations • Two operations are in conflict, if their combined effect depends on the order they are executed. • The effect of an operation refers to • The value of an object set by a write operation • The result returned by a read operation. • Two transactions are serially equivalent, iff all pairs of conflicting operations are executed in the same order for all objects (data) they both access. • Serial equivalence is the basis for concurrency control protocols for transactions.

12. Operations of different Conflict Reason transactions read read No Because the effect of a pair of read operations does not depend on the order in which they are executed read write Yes Because the effect of a read and a write operation depends on the order of their execution write write Yes Because the effect of a pair of write operations depends on the order of their execution Read and Write Operation Conflict Rules

13. Non-serially equivalent interleaving of operations Conflicting Ops. Conflicting Operators Example Transaction T1 Transaction T2 x= a.read() a.write(20)y = b.read() b.write(30) b.write(x) z = a.read() x= a.read() a.write(20)z = a.read() b.write(x) y = b.read() b.write(30) Serially equivalent interleaving of operations

14. Transaction T : Transaction U : balance = b.getBalance() balance = b.getBalance() b.setBalance(balance*1.1) b.setBalance(balance*1.1) a.withdraw(balance/10) c.withdraw(balance/10) balance = b.getBalance() $200 b.setBalance(balance*1.1) $220 balance = b.getBalance() $220 b.setBalance(balance*1.1) $242 a.withdraw(balance/10) $80 c.withdraw(balance/10) $278 Serially equivalent interleaving of T and U T always executes the first operation of all three pairs of conflicting operations

15. Transaction T : Transaction U : balance = b.getBalance() balance = b.getBalance() b.setBalance(balance*1.1) b.setBalance(balance*1.1) a.withdraw(balance/10) c.withdraw(balance/10) balance = b.getBalance() $200 b.setBalance(balance*1.1) $220 balance = b.getBalance() $220 b.setBalance(balance*1.1) $242 a.withdraw(balance/10) $80 c.withdraw(balance/10) $278 A Serially Equivalent Interleaving of T and U

16. : Transaction V : Transaction W a.withdraw(100) aBranch.branchTotal() b.deposit(100) a.withdraw(100); $100 total = a.getBalance() $100 total = total+b.getBalance() $300 total = total+c.getBalance() b.deposit(100) $300 Inconsistent Retrievals Problem Both withdraw and deposit contain a write operation

17. Transaction V : Transaction W : a.withdraw(100); aBranch.branchTotal() b.deposit(100) $100 a.withdraw(100); $300 b.deposit(100) $100 total = a.getBalance() $400 total = total+b.getBalance() total = total+c.getBalance() ... A Serially Equivalent Interleaving of V and W

18. Transaction T : Transaction U : a.getBalance() a.getBalance() a.setBalance(balance + 10) a.setBalance(balance + 20) balance = a.getBalance() $100 a.setBalance(balance + 10) $110 balance = a.getBalance() $110 a.setBalance(balance + 20) $130 commit transaction abort transaction A Dirty Read When Transaction T Aborts • Any transaction (like U) that may encounter a dirty read delays its commit operation. • U delays its commit until after T commits. In the case that T aborts, U aborts as well. • To avoid cascading aborts, transactions are only allowed to read objects that were written • committed transactions.

19. Transaction T : Transaction U : a.setBalance(105) a.setBalance(110) $100 a.setBalance(105) $105 a.setBalance(110) $110 Overwriting Uncommitted Values • The action of abort is implemented by restoring “before images” • of all the Writes of a transaction. • The before image of T’s write is $100. • The before image of U’s write is $105. • If T commits and U aborts  $105 • If U commits and T aborts  $100 ($110 is the correct value) • If T aborts and U aborts  $105 ($100 is the correct value) • If U aborts and T aborts  $100 • Write operations must be delayed until earlier transactions that • updated the same objects have either committed or aborted.

20. Nested Transactions • Transactions can be composed of other subtransactions • A subtransaction appears atomic to its parent, w.r.t failure and concurrent access. • Subtransactions on the same level can run concurrently, subject to serialization. T: top-level Trans T2: Subtrans. T1: Subtrans. T21: Subtrans. T12: Subtrans. T11: Subtrans.

21. Nested Transactions Commitment Rules • A transaction can commit/abort only after all its children have completed. • A subtransaction decides to provisionally commit (PROV) or abort. • When a transaction aborts, all its children are also aborted. • When a subtransaction aborts, the parent can decide to abort or commit. • When the top-level trans. commits, all subtrans that have PROVed also commit.

22. T : top-level transaction T = openSubTransaction T = openSubTransaction 1 2 commit T : T : 1 2 openSubTransaction openSubTransaction openSubTransaction prov. commit abort T T : T : : 21 11 12 openSubTransaction prov. commit prov. commit prov. commit T : 211 prov.commit Nested transactions