14/06/2015Distribuerede Systemer1 Concurrency Control Thomas Hildebrandt

14/06/2015Distribuerede Systemer2 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

14/06/2015Distribuerede Systemer3 Concurrency Control Protocols challenges 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)

14/06/2015Distribuerede Systemer4 Locks Two-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?

14/06/2015Distribuerede Systemer5 Considering aborts Strict 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?

14/06/2015Distribuerede Systemer6 Deadlocks definition 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: B A Waits for Held by T U U T Waits for

14/06/2015Distribuerede Systemer7 Additional deadlock conditions Two or more processes share resources which they use under mutual exclusion (for instance by using locks) Incremental acquisition No preemption

14/06/2015Distribuerede Systemer8 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

14/06/2015Distribuerede Systemer9 Distributed Deadlocks global wait-for graphs: D Waits for Waits for Held by Held by B Waits for Held by X Y Z Held by W U V A C W V U

14/06/2015Distribuerede Systemer10 Global wait-for graphs phantom deadlocks X TU Y VT T U V local wait-for graph global deadlock detector may use edge-chasing algorithm instead

14/06/2015Distribuerede Systemer11 Increasing Concurrency fine-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

14/06/2015Distribuerede Systemer12 Read and write locks Figure 12.15: Lock compatibility For one objectLock requested readwrite Lock already set noneOK readOKwait writewait - 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?

14/06/2015Distribuerede Systemer13 Use of locks in strict two-phase locking Figure 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.

14/06/2015Distribuerede Systemer14 Lock Implementation Figure 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)){/*...*/ } }

14/06/2015Distribuerede Systemer15 Lock Implementation Figure 12.17, release public synchronized void release(TransID trans ){ holders.removeElement(trans); // remove this holder // set locktype to none notifyAll(); }

14/06/2015Distribuerede Systemer16 Increasing Concurrency Hierarchic Locks - Figure Diary-example: locking with mixed granularity: Week MondayTuesdayWednesdayThursdayFriday 9:00–10:00 time slots 10:00–11:0011:00–12:0012:00–13:0013:00–14:0014:00–15:0015:00–16:00 Use intention locks to get efficient locking

14/06/2015Distribuerede Systemer17 Lock compatibility table for hierarchic locks Figure For one object Lock to be set readwriteI-readI-write Lock already set none OK read OKwaitOKwait write wait I-read OKwaitOK I-write wait OK

14/06/2015Distribuerede Systemer18 Increasing Concurrency Nested transactions children borrows locks parent inherit locks from children why may use of nested transactions increase concurrency?

14/06/2015Distribuerede Systemer19 Increasing Concurrency Two-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

14/06/2015Distribuerede Systemer20 Lock compatibility table (read, write, commit) Figure For one objectLock to be set readwritecommit Lock already setnoneOK readOK wait writeOKwait commitwait

14/06/2015Distribuerede Systemer21 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)

14/06/2015Distribuerede Systemer22 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)

14/06/2015Distribuerede Systemer23 Optimistic Concurrency Control validation of transaction T TTiTi Rule writeread1.TiTi must not read objects written byT readwrite2.T must not read objects written byTiTi write 3.TiTi must not write objects written byTand T mustnot write objects written byTiTi may make update phase mutual exclusive, (- use locks) either validate backward or forward

14/06/2015Distribuerede Systemer24 Validation of transactions Figure Earlier committed transactions WorkingValidationUpdate T 1 T v Transaction being validated T 2 T 3 Later active transactions active 1 2

14/06/2015Distribuerede Systemer25 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

14/06/2015Distribuerede Systemer26 Optimistic Concurrency Control distributed 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

14/06/2015Distribuerede Systemer27 Timestamp ordering validation on the fly assign unique timestamp at openTransaction –check conflicts on the fly –as two-version locking, but decides order statically

14/06/2015Distribuerede Systemer28 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