1. 1 Distribuerede systemer og sikkerhed – 18. marts 2002 zFrom Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design zEdition 3, © Addison-Wesley 2001 Presentation based on slides for the book: Slides modified by Jens B Jorgensen, University of Aarhus

2. 2 Chapter 12: Transactions and Concurrency Control From Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edition 3, © Addison-Wesley 2001

3. 3 Transactions – basics zSystem model: One server, multiple clients. zGoal: Objects at server remain consistent. zFailure model: Server crashes, omission failures, arbitrary delays. zTransaction: ySet of operations on objects to be performed as an indivisible unit by the server. yServer must guarantee that either the entire transaction is carried out and the results recorded in permanent storage or (if crash) its effects are completely erased. zEssential properties: ACID.

4. 4 Transactions – bank server 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 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 Operations of the Branch interface Operations of the Account interface

5. 5 Transactions – a client’s banking transaction Transaction T: a.withdraw(100); b.deposit(100); c.withdraw(200); b.deposit(200);

6. 6 Transactions – life histories SuccessfulAborted by clientAborted by server openTransaction operation server aborts transaction operation operation ERROR reported to client closeTransactionabortTransaction Coordinator interface: openTransaction() -> trans; closeTransaction(trans) -> (commit,abort); abortTransaction(trans);

7. 7 Concurrent transactions – the lost update problem TransactionT: balance = b.getBalance(); b.setBalance(balance*1.1); a.withdraw(balance/10) TransactionU: balance = b.getBalance(); b.setBalance(balance*1.1); c.withdraw(balance/10) balance = b.getBalance(); $200 balance = b.getBalance(); $200 b.setBalance(balance*1.1); $220 b.setBalance(balance*1.1); $220 a.withdraw(balance/10) $80 c.withdraw(balance/10) $280

8. 8 Concurrent transactions – the inconsistent retrievals problem TransactionV: a.withdraw(100) b.deposit(100) TransactionW : aBranch.branchTotal() a.withdraw(100); $100 total = a.getBalance() $100 total = total+b.getBalance() $300 total = total+c.getBalance() b.deposit(100) $300

9. 9 Concurrent transactions – serial equivalence zIf “correct” transactions are done one at a time in some order, the combined effect will also be correct. zA serially equivalent interleaving: An interleaving of the operations of transactions in which the combined effect is the same as if the transactions had been performed one at a time in some order. zSerial equivalence prevents lost updates and inconsistent retrievals.

10. 10 Concurrent transactions – a serially equivalent interleaving of T and U TransactionT: balance = b.getBalance() b.setBalance(balance*1.1) a.withdraw(balance/10) TransactionU: balance = b.getBalance() b.setBalance(balance*1.1) 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

11. 11 Concurrent transactions – a serially equivalent interleaving of V and W TransactionV: a.withdraw(100); b.deposit(100) TransactionW: aBranch.branchTotal() a.withdraw(100); $100 b.deposit(100) $300 total = a.getBalance() $100 total = total+b.getBalance() $400 total = total+c.getBalance()...

12. 12 Concurrent transactions – conflicting operations zTwo operations conflict iff their combined effect depends on the order in which they are executed. zFor two transactions to be executed serially equivalent, it is necessary and sufficient that all pairs of conflicting operations of the two transactions be executed in the same order at all of the objects they both access.

13. 13 Concurrent transactions – read and write operation conflict rules Operations of different transactions ConflictReason read NoBecause the effect of a pair ofread operations does not depend on the order in which they are executed readwriteYesBecause the effect of aread and awrite operation depends on the order of their execution write YesBecause the effect of a pair ofwrite operations depends on the order of their execution

14. 14 Concurrent transactions – interleaving of operations of transactions T and U TransactionT: U: x = read(i) write(i, 10) y = read(j) write(j, 30) write(j, 20) z = read (i) Serially equivalent?

15. 15 Aborting transactions – dirty read TransactionT: a.getBalance() a.setBalance(balance + 10) TransactionU: a.getBalance() 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

16. 16 Aborting transactions – premature writes TransactionT: a.setBalance(105) TransactionU: a.setBalance(110) $100 a.setBalance(105)$105 a.setBalance(110)$110

17. 17 Aborting transactions – strict execution zA transaction delays both read and write operations on an object, until all transactions that previously wrote that object have either committed or aborted. zOther issues: yCascading aborts. yTentative versions.

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

19. 19 Locks – example

20. 20 Locks – locking schemes zExclusive locks: yThe server attempts to lock any object that is about to be used by any operation of a client’s transaction. yIf a client requests access to an object that is already locked, the request is suspended and the client must wait. zTwo-phase locking: yA transaction is not allowed any new locks after it has released a lock. yGrowing phase: New locks are acquired. yShrinking phase: Locks are released. zStrict two-phase locking: Any locks acquired during the progress of a transaction are held until the transaction commits or aborts. zConcurrency control granularity an import issue.

21. 21 Locks – read and write locks zAllow several concurrent transactions to read an object. zEnsure exclusive access for writing. For one objectLock requested readwrite Lock already set noneOK readOKwait writewait

22. 22 Locks – read and write locks in strict two-phase locking 1. When an operation accesses an object within a transaction: (a)If the object is not already locked, it is locked and the operation proceeds. (b)If the object has a conflicting lock set by another transaction, the transaction must wait until it is unlocked. (c)If the object has a non-conflicting lock set by another transaction, the lock is shared and the operation proceeds. (d)If the object has already been locked in the same transaction, the lock will be promoted if necessary and the operation proceeds. (Where promotion is prevented by a conflicting lock, rule (b) is used.) 2. When a transaction is committed or aborted, the server unlocks all objects it locked for the transaction.

23. 23 Deadlocks – basics TransactionT U OperationsLocksOperationsLocks a.deposit(100); write lockA b.deposit(200) write lockB b.withdraw(100) waits forU’sa.withdraw(200);waits forT’s lock onB A Deadlock: Each member of a group of transactions is waiting for some other member to release a lock.

24. 24 Deadlocks – wait-for graphs B A Waits for Held by T U U T Waits for Representation of waiting relationship between ongoing transactions. Deadlocks correpond to cycles. To recover from a deadlock, break a cycle.

25. 25 Deadlocks – resolution via timeouts Transaction TTransaction U OperationsLocksOperationsLocks a.deposit(100); write lock A b.deposit(200) write lock B b.withdraw(100) waits for U ’s a.withdraw(200); waits for T’s lock onB A (timeout elapses) T’s lock onA becomes vulnerable, unlockA, abort T a.withdraw(200); write locksA unlockA, B

26. 26 Optimistic concurrency control – motivation zLocking may result in overhead, deadlocks, and reduced concurrency. zObservation: In most applications, the likelihood of two clients’ transactions accessing the same object is low. zMethod: Go ahead, but do check upon closeTransaction!

27. 27 Optimistic concurrency control – transaction phases zWorking phase: yEach transaction has a tentative version of each of the objects that it updates. yRead set and write set maintained. zValidation phase: yWhen the closeTransaction request is received, the transaction is validated to establish whether or not its operations on objects conflict with operations of other transactions. yIf success the commit. yIf fail then some transaction must be aborted. zUpdate phase: yRecord changes to tentative versions as permanent.

28. 28 Optimistic concurrency control – overall validation strategy zUse read-write conflict rules. zFor a given transaction, ensure serial equivalence with all other overlapping transactions. zTransactions are assigned increasing numbers when they enter validation phase. zAssumption: At any time, at most one transaction is in the validation and update phase.

29. 29 Optimistic concurrency control – validation rules TvTv TiTi Rule writeread1.TiTi must not read objects written byTvTv readwrite2.TvTv must not read objects written byTiTi write 3.TiTi must not write objects written byTvTv and TvTv mustnot write objects written byTiTi Serializability of transactions Tv and Ti:

30. 30 Optimistic concurrency control – validation algorithms Backward validation of transaction T v boolean valid = true; for (int T i = startTn+1; T i <= finishTn; T i ++){ if (read set of T v intersects write set of T i ) valid = false; } Forward validation of transaction T v boolean valid = true; for (int T id = active1; T id <= activeN; T id ++){ if (write set of T v intersects read set of T id ) valid = false; }

31. 31 Optimistic concurrency control – validation example Earlier committed transactions WorkingValidationUpdate T 1 T v Transaction being validated T 2 T 3 Later active transactions active 1 2

32. 32 Summary zTransactions: yConcurrent transactions (serial equivalence). yAborting transactions. y(Nested transactions). zLocks: yTwo-phase locking. yStrict two phase-locking. yDeadlocks. zOptimistic concurrency control: yBackward validation. yForward validation.