Concurrency Control

1. Concurrency Control Thomas Hildebrandt Distribuerede Systemer

2. Agenda • concurrency control protocols: challenges • pessimistic concurrency control • Locks • (strict) two-phase locking • Deadlocks • prevention and detection • distributed deadlocks • Increasing concurrency • fine-grained locking, two-version locking, nested transactions • optimistic concurrency control • working, validation and updating phase Distribuerede Systemer

3. Concurrency Control Protocolschallenges • recall the notions of • isolation, serial equivalence and conflicting operations • challenge of concurrency control protocols: • guarantee isolation property and maximize concurrency • may be used without using transactions (e.g. the CORBA Concurrency Control Service), • but if used with transactions, we must consider aborts • pessimistic versus optimistic approach: • avoid conflicts (locking) or resolve conflicts (aborting) Distribuerede Systemer

4. LocksTwo-phase locking • a lock controls access to an object: • a lock can be acquired and released • simplest locks are exclusive locks • transaction manager employs a lock manager that controls a lock for each shared object • two-phase locking • growing phase & shrinking phase: no new locks after having released a lock • guarantees serial equivalence in absense of failures/aborts • what may go wrong? Distribuerede Systemer

5. Considering abortsStrict two-phase locking • recall that aborts may lead to • dirty reads (, cascading aborts) and • premature writes • to avoid this we ensure strict execution: • no reads and writes on objects with non-comitted updates • this is guaranteed by strict two-phase locking • hold locks until commit (and everything is saved) or abort • have to wait to all have committed in distributed settings • What may still go wrong? Distribuerede Systemer

6. Held by Waits for A T U U T B Waits for Held by Deadlocksdefinition • a state in which each member of a group of transactions is waiting for some other member to release a lock This situation can be represented by a wait-for graph: Distribuerede Systemer

7. Additional deadlock conditions • Two or more processes share resources which they use under mutual exclusion (for instance by using locks) • Incremental acquisition • No preemption Distribuerede Systemer

8. Dealing with deadlocks • Deadlock prevention • rule out one or more of the conditions for deadlock, for instance by locking in a fixed order or pre-lock • Deadlock detection • alternatively one may try to detect deadlocks • to resolve the deadlock a transaction must be aborted • Timeouts on locks • common, but may lead to unnecessary aborts • penalizes long transactions Distribuerede Systemer

9. W W Waits for Held by D C A X Z V Held Held by by Waits for U V U Waits for B Held by Y Distributed Deadlocks • global wait-for graphs: Distribuerede Systemer

10. local wait-for graph local wait-for graph global deadlock detector T V T T U V U Y X Global wait-for graphsphantom deadlocks may use edge-chasing algorithm instead Distribuerede Systemer

11. Increasing Concurrencyfine-grained locking • read & write locks • allow many concurrent readers • policy issues (fairness) • hierarchic locks • locking with mixed granularity • nested transactions • two-version locking • tentative versions Distribuerede Systemer

12. For one object Lock requested read write Lock already set none OK OK read OK wait write wait wait Read and write locksFigure 12.15: Lock compatibility - what should happen in strict two-phase locking, if a transaction first gets a READ lock, and then asks for a WRITE lock on the same object? Distribuerede Systemer

13. Use of locks in strict two-phase lockingFigure 12.16 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. Distribuerede Systemer

14. Lock ImplementationFigure 12.17, acquire public class Lock { private Object object; // the object being protected by the lock private Vector holders; // the TIDs of current holders private LockType lockType; // the current type public synchronized void acquire(TransID trans, LockType aLockType ){ while(/*another transaction holds the lock in conflicing mode*/) { try { wait(); }catch ( InterruptedException e){/*...*/ } } if(holders.isEmpty()) { // no TIDs hold lock holders.addElement(trans); lockType = aLockType; } else if(/*another transaction holds the lock, share it*/ ) ){ if(/* this transaction not a holder*/) holders.addElement(trans); } else if (/* this transaction is a holder but needs a more exclusive lock*/) while(!lockType.promote(aLockType)){ try{wait(); } catch(InterruptedException e)){/*...*/ } } } Distribuerede Systemer

15. Lock ImplementationFigure 12.17, release public synchronized void release(TransID trans ){ holders.removeElement(trans); // remove this holder // set locktype to none notifyAll(); } } Distribuerede Systemer

16. Week Monday Tuesday Wednesday Thursday Friday time slots 9:00–10:00 10:00–11:00 11:00–12:00 12:00–13:00 13:00–14:00 14:00–15:00 15:00–16:00 Increasing Concurrency Hierarchic Locks - Figure 12.26 Diary-example: locking with mixed granularity: Use intention locks to get efficient locking Distribuerede Systemer

17. Lock to be set For one object read write I-read I-write Lock already set none OK OK OK OK read OK wait OK wait write wait wait wait wait I-read OK wait OK OK I-write wait wait OK OK Lock compatibility table for hierarchic locksFigure 12.27 Distribuerede Systemer

18. Increasing ConcurrencyNested transactions • children borrows locks • parent inherit locks from children • why may use of nested transactions increase concurrency? Distribuerede Systemer

19. Increasing ConcurrencyTwo-version locking • "optimistic scheme" • write to tentative versions • read tentative or last committed values • check at commit time for conflicts • uses read, write and commit locks • comparison with one-version locking: • read operations only delayed during commit • read operations may cause delay in other committing transactions Distribuerede Systemer

20. For one object Lock to be set read write commit Lock already set none OK OK OK read OK OK wait write OK wait commit wait wait Lock compatibility table (read, write, commit)Figure 12.24 Distribuerede Systemer

21. Optimistic Concurrency Control • drawbacks of locking: • lock maintance is an overhead, only needed in worst case • may lead to deadlocks, deadlock prevention reduces concurrency • Instead one may take an optimistic approach: • no locking • working, validation and update phase • use tentative versions in working phase (like two-version locking) Distribuerede Systemer

22. Optimistic Concurrency Control • Working phase: • use tentative versions (as two-version locking, but no locks!) • several different values of an object may coexist • keep record of objects accessed: • read set and write set • Validation phase • starts at closeTransaction request, • assign transaction number, acts as a "pseudo clock" • validate order of conflicting pairs wrt. overlapping transactions (not yet committed) Distribuerede Systemer

23. Optimistic Concurrency Controlvalidation of transaction T T Ti Rule write read 1. Ti must not read objects written by T read write 2. T must not read objects written by Ti write write 3. Ti must not write objects written by T and T must not write objects written by Ti • may make update phase mutual exclusive, (- use locks) • either validate backward or forward Distribuerede Systemer

24. Working Validation Update T 1 Earlier committed transactions T 2 T 3 Transaction T being validated v active 1 Later active active 2 transactions Validation of transactionsFigure 12.28 Distribuerede Systemer

25. Validation • backward • write-only transactions always pass • must keep old write sets • can only abort the transaction under validation to resolve • forward • read-only transactions always pass • read sets of active may change during validation • can choose alternative resolvation (abort active in conflict) • starvation • transactions are normally restarted after aborts, we say they starve if they keep aborting this way Distribuerede Systemer

26. Optimistic Concurrency Controldistributed transactions • local concurrency control • validation takes place in phase one at each server • commitment deadlock may occur if using exclusive validation • parallel validation • must check rule 3 as well • need to ensure global order • finish with a global validation, or • issue globally unique transaction numbers Distribuerede Systemer

27. Timestamp orderingvalidation on the fly • assign unique timestamp at openTransaction • check conflicts on the fly • as two-version locking, but decides order statically Distribuerede Systemer

28. Summary and conclusions • concurrency control protocols must ensure isolation - and allow for recovery • they all induce an overhead and limit the potential for concurrent operation • locking may lead to deadlocks • optimistic approaches more efficient if few conflicts, mut may lead to late aborts • timestamp ordering decides order statically and aborts immediately • distributed transactions: distributed control Distribuerede Systemer