C ONCURRENCY C ONTROL Prasun Dewan Department of Computer Science - PowerPoint PPT Presentation

T RANSACTIONS (R EVIEW )  A (tomic)  Either all action of a transaction occur or none  C (onsistent)  Each transaction leaves shared state in a consistent state, where consistency is application-defined  I (solation)  Actions of concurrent transactions are isolated so that together they leave the shared state in a consistent state  D (urability)  Actions of a transaction persist – written to stable storage) vs. persistent storage  Stable – atomic write no errors;  Persistent – errors possible 45

T RADITIONAL I SOLATION CRITERIA : S ERIALIZABILITY (R EVIEW )  Concurrent transactions execute as if they were submitted one after the other, leaving data in consistent state all possible schedules serializable schedules 46 46

V ALIDATION /C HECKING T IME (R EVIEW )  Pessimistic  Early  Failure => block  Optimistic  Late  Failure => abort  Interactive transaction?  Wasted human work not redoable perhaps  Merging  Late, not serializable  Merging, new transaction to replace conflicting transactions 47 47

L OCKING : O NE I TEM (R EVIEW ) T 1 T 2 T 1 T 2 W 1 (d 1 ) L 1 (d 1 ) L 2 (d 1 ) W 1 (d 1 ) W 2 (d 1 ) R 2 (d 1 ) R 1 (d 1 ) R 1 (d 1 ) F 1 (d 1 ) W 2 (d 1 ) R 2 (d 1 ) F 1 (d 1 ) 48 48

L OCK C OMPATIBILITY M ATRIX Data Item D Locked Unlocked Lock No Yes Issues (in collaborative systems)? 49

L OCK C OMPATIBILITY M ATRIX (R EVIEW ) Data Item D Locked Unlocked Lock No Yes Issues (in collaborative systems)? 50

I SSUES Lock Denial Semantics? User Interface for Locking and Unlocking? Implementation of locking in a distributed collaborative environment? 51

L OCK D ENIAL UI Thread should not Synchronous: Programmed blocked until lock given block Synchronous with timeout: Like synchronous but timeout returns false Asynchronous: Callback when lock given Non blocking: Callback when lock available, try again Non blocking: No callback, polling 52

I SSUES  Lock Denial Semantics? User Interface for Locking and Unlocking? Implementation of locking in a collaborative environment? 53

U SER -I NTERFACE Explicit/Implicit Locking Explicit/Implicit Unlocking 54

UI: E XPLICIT /I MPLICIT L OCKING Lock O Explicit Append O, E1 Delete O, E2 Selection-implied Select Object  Lock Object + Select Object Key-implied Press Key  Lock Buffer + Process Key Dragging-implied Start Dragging  Lock Object + Start Dragging 55

E XPLICIT /I MPLICIT U NLOCKING Append O, E1 Explicit Delete O, E2 Unlock O Unselect Object  Unselect object + Unlock Selection-implied object Key-implied Release Key  Unlock Buffer + Unlock object Stop Dragging  Stop Dragging + Unlock Dragging-implied Object Analogues of explicit/implicit locking 56

I MPLICIT U NLOCKING Tickle locks Timeout  Unlock Object Preemptive locks Lock Object  Unlock Object + Lock Object Tickle + Timeout + Lock Object  Unlock Object + Lock Preemptive Object Unlocked object may not be consistent! Unlocking user may be able to restore consistency of another user to essentially do a joint (nested) transaction 57

C ONSISTENCY VS C ONCURRENCY Non-Preemptive Preemptive Tickle-Locks Lock O Lock O Lock O Insert O, E1 Insert O, E1 Insert O, E1 Delete O, D1 t > T Unlock O Lock O Insert O, E2 Lock O Lock O … Insert O, E2 Insert O, E2 … … Pro: Low Wait Time Pro: Forgetting to Pro: Consistency Pro: Priority unlock 58

I SSUES  Lock Denial Semantics?  User Interface for Locking and Unlocking? Implementation of locking in a collaborative environment? 59

I MPLEMENTATION Need to share a locking model among multiple users Already know how to share an object 60

R EPLICATED VS C ENTRALIZED Interactor Interactor Interactor Model Model Model Interactor 61

R EPLICATED VS C ENTRALIZED Lock Lock Lock Interactor Interactor Interactor Lock Model Lock Model Lock Model Lock Interactor 62

R EPLICATED M ODEL : I SSUES Lock Lock Interactor Interactor Lock Model Lock Model Who solves the consistency problems of the consistency enforcer! Consistency issues of causality and concurrent operations (to be addressed later) Correctness and performance issues when model is non deterministic, accesses central resources, and has side effects 63

D ISTRIBUTED C ONSENSUS P ROBLEM A set of processes have to agree on a common value (Byzantine generals) There may be failures in machines and communication Some processes may be malicious 2 Phase Commit : Coordinator takes vote in first phase and reports majority outcome in second Not to be confused with 2 Phase Locking (later) Will simply use the centralized cache solutions assuming no faults 64

D ISTRIBUTION U NAWARE I NTERACTOR W ITH M ODEL C ACHE /P ROXY Model cache is a proxy that forwards write (lock, release) Lock Model operation without changing Interactor Cache its data Read operations (checking lock) access cached data Lock Model 65

R EQUEST FOR L OCKED R ESOURCE L I 1 Locked(I 2 ) Locked(I 2 ) I 2 Locked(I 2 ) 66

R EQUEST FOR U NLOCKED R ESOURCE L Locked(I 1 ) I 1 Free Locked(I 1 ) Free Locked(I 1 ) Free I 2 67

F REE R EQUEST FOR L OCKED R ESOURCE F Free I 1 Locked(I 1 ) Locked(I 2 ) Free I 2 Locked(I 2 ) Free 68

D ISTRIBUTION U NAWARE I NTERACTOR W ITH M ODEL C ACHE /P ROXY Model cache is a proxy that forwards write (lock, release) Lock Model operation without changing Interactor Cache its data Read operations (checking lock) access cached data Lock Model Works? What if a message takes a long time to reach its destination? Acquire (L) and Release(F) Messages 69

C ONCURRENT L OCK R EQUEST : M ESSAGE TO S ECOND L OCKER D ELAYED L Locked(I 1 ) I 1 Free Locked(I 1 ) Free L Locked(I 1 ) Free I 2 70

C ONCURRENT L OCK R EQUEST : M ESSAGE TO F IRST L OCKER D ELAYED L Locked(I 1 ) I 1 Free At most one cache will make transition from free to locked Locked(I 1 ) Free L Locked(I 1 ) Free I 2 71

C ONCURRENT F REE /L OCK R EQUEST F Locked(I2) L Free I 1 Locked(I 1 ) Caches are not consistent! Locked(I 2 ) Free Conservative: Local cache needs to be invalidated after each write L I 2 Locked(I2) Locked(I 2 ) Free Using application semantics for more concurrency? 72

I MMEDIATE F REEING (A PPLICATION S EMANTICS ) Model cache is a proxy that F forwards write (lock, release) L operation without changing I 1 Locked(I 1 ) Free its data Release requests cause Free immediate freeing Locked(I 1 ) L Free I 2 Locked(I 2 ) 73

I MMEDIATE L OCKING ? Weak/eventual consistency: L pay the price Locked(I 1 ) I 1 Free Optimistic locks: undo changes if lock request denied May have received changes Locked(I 1 ) Free from others, must undo non last changes or block them Others may have seen changes – must do distributed L undo if changes sent Locked(I 1 ) Locked(I 2 ) Free I 2 74

O PTIMISTIC L OCKING 3. Undo if lock request fails, 1. Perform operation o and put it and perform deferred in undo log received actions 2. Send permission to perform 4. Othewrise, toOthers() operation and defer performing send operation and received operations perform deferred receive operations PC 2 Undo Log Received PC Log 1 color O drag O drag O PC 3 Lock Manager Better response time 75 75 e

D ISTRIBUTION U NAWARE I NTERACTOR W ITH M ODEL C ACHE /P ROXY Model cache is a proxy that forwards lock operation Lock Model Interactor without changing its data and Cache forwards release request after changing its data Read operations (checking Lock Model lock) access cached data Distributed vs software architecture 76

S INGLE -U SER P ATTERN Put locking semantics in L model? Lockable I 1 Free Model May have more than one kind of concurrency controller (optimistic, pessimistic) May have more than one controller (access, concurrency) 77

V ETOERS VS O BSERVERS Observable Observer Vetoer (Listenable) (Listener) Vetoer 1 Interactor 1 write method Vetoer 2 Model Interactor 2 Vetoer 3 Interactor 3 Change Permission Vetoer 4 Interactor 4 Announced Sought 78

O BSERVER VS . V ETOER Observer 1 register() operation register() Observer 2 Observable operation Observers notified after event processing done 79

O BSERVER VS . V ETOER Vetoer 1 register() operation register() Vetoer 2 Vetoeable operation Vetoers checked with before event processing done Feedback, so notifier must wait in distributed implementation 80

V ETOERS  Like an observer, a vetoer can be registered with an object  The object checks with each vetoer before making and announcing change  If a singe vetoer rejects change, then it is not made or announced  Java Beans comes with standard Vetoer interface 81

V ETOERS (R EVIEW )  Like an observer, a vetoer can be registered with an object  The object checks with each vetoer before making and announcing change  If a singe vetoer rejects change, then it is not made or announced  Java Beans comes with standard Vetoer interface 82

S TANDARD J AVA V ETOER I NTERFACE public interface VetoableChangeListener { public void vetoableChange(PropertyChangeEvent evt) throws PropertyVetoException } Vetoing is not an exception (error)! Better to return a Boolean value 83

C ONTROLLED R EPLICATED H ISTORY public class AControlledReplicatedHistory<ElementType> extends AReplicatedSimpleList<ElementType> implements ControlledReplicatedHistory<ElementType> { VetoableChangeSupport vetoableChangeSupport = new VetoableChangeSupport(this); public synchronized void replicatedAdd(ElementType aNewValue) { try { vetoableChangeSupport.fireVetoableChange( "IMHistory", null, aNewValue); } catch (PropertyVetoException e) { Fitting list add to property change – return; old value is null, property name } could be also super.replicatedAdd(aNewValue); } public void addVetoableChangeListener( VetoableChangeListener listener) { vetoableChangeSupport.addVetoableChangeListener(listener); } … 84

L IBRARY L ISTENABLE E VENT Q UEUE Collaboration-Unaware Application a^, w 2 , x, y a^, w 2 , x, y a^, w 2 , x, y AnExtendible ListeningInput InputController AWTEventQueue Distributer a^, w 2 , x, y Collaboration-Unaware Window System 85

H OW TO I NTERCEPT , I NJECT AND V ETO W INDOW E VENTS static addEventQueueHandler getEventQueue() (AWTEventQueueHandler) getCommunication dispatchReceivedEvent AnExtendible EventSupport() (AWTEvent) AWTEventQueue addVetoableChangeListener (VetoableChangeListener) The property value of fired vetoable change is the AWTEvent and the property name is to be ignored 86

D ISTRIBUTED + S OFTWARE A RCHITECTURE Lock Model Vetoer 1 Interactor Cache register() operation Lock Model Vetoeable Local Model Cache = Vetoeable Model + Slave Model Vetoer Lock Model = Master Lock Model Assume each site has Slave Model Vetoer and one of these sites has Master Lock Model Three relevant user operations: write, lock, release 87

T RACEABLE A WARE S LAVE UI T HREAD Slave UI Thread (Vetoer) For each vetoable write received from local user U If not getLock(U), UserActionDenied Slave UI Thread (Lock Grantor) For each SlaveLockGrantRequestMade by local user U if not locked(U), to all, SlaveLockGrantRequestSent Slave UI Thread (Lock Releaser) For each SlaveLockReleaseRequestMade by local user U If locked(U), setLock(U, false), to all, SlaveLockReleaseRequestSent 88

T RACEABLE A WARE M ASTER R ECEIVING T HREADS Master Receiving Thread For each MasterLockRequestReceived If not isLocked(), MasterLockGranted, to all, MasterLockGrantStatusSent Master Receiving Thread For each MasterLockReleaseRequestReceived from user U If getLock(U), MasterLockReleased, to all, MasterLockReleaseStatusSent 89

T RACEABLE A WARE S LAVE R ECEIVING T HREADS Slave Receiving Thread For each SlaveLockGrantReceived to A by U SlaveLockGranted; If (A == U), SlaveMyLockGrantMadeReceived Provide awareness Slave Receiving Thread For each SlaveLockRelease Received SlaveLockReleased Provide awareness 90

S UMMARY  Concurrency Control and Transactions  Simple Locking – One Lock – and its distributed implementation Multiple Locks Multiple (Programmer-Defined) Lock Types Alternatives to Locking Nested transactions 91

L OCKING : O NE I TEM (R EVIEW ) T 1 T 2 T 1 T 2 W 1 (d 1 ) L 1 (d 1 ) L 2 (d 1 ) W 1 (d 1 ) W 2 (d 1 ) R 2 (d 1 ) R 1 (d 1 ) R 1 (d 1 ) F 1 (d 1 ) W 2 (d 1 ) R 2 (d 1 ) F 1 (d 1 ) 92

L OCKING M ULTIPLE I TEMS IN S AME O RDER T 1 T 2 T 1 T 2 W 1 (d 1 ) L 1 (d 1 ) W 2 (d 1 ) W 1 (d 1 ) L 2 (d 1 ) F 1 (d 1 ) W 2 (d 2 ) W 2 (d 1 ) L 1 (d 2 ) W 1 (d 2 ) F 2 (d 1 ) W 1 (d 2 ) L 2 (d 2 ) F 1 (d 2 ) W 2 (d 2 ) F 2 (d 2 ) T 2 performs an operation on each object after T 1 93

L OCKING M ULTIPLE I TEMS IN D IFFERENT O RDER T 1 T 2 T 1 T 2 W 1 (d 1 ) L 1 (d 1 ) W 2 (d 2 ) W 1 (d 1 ) L 2 (d 2 ) F 1 (d 1 ) W 2 (d 1 ) W 2 (d 2 ) F 2 (d 2 ) W 1 (d 2 ) L 1 (d 2 ) L 2 (d 1 ) W 1 (d 2 ) W 2 (d 1 ) F 1 (d 2 ) F 2 (d 1 ) Locks were freed too quickly! Two phase locking Get all locks before doing any operation? A transaction has a growing phase when locks are added and not released Early binding and keeps locks for longer than necessary Then it has a shrinking phase when locks are released but not freed 94

N ON T WO P HASE IN S AME O RDER T 1 T 2 T 1 T 2 W 1 (d 1 ) L 1 (d 1 ) W 2 (d 1 ) W 1 (d 1 ) L 2 (d 1 ) F 1 (d 1 ) W 2 (d 2 ) W 2 (d 1 ) L 1 (d 2 ) W 1 (d 2 ) F 2 (d 1 ) W 1 (d 2 ) L 2 (d 2 ) F 1 (d 2 ) W 2 (d 2 ) F 2 (d 2 ) Locks shrink and then grow 95

T WO P HASE L OCKING IN S AME O RDER T 1 T 2 T 1 T 2 W 1 (d 1 ) L 1 (d 1 ) W 2 (d 1 ) W 1 (d 1 ) L 2 (d 1 ) W 2 (d 2 ) L 1 (d 2 ) 1 2 (d 2 ) F 1 (d 1 ) W 1 (d 2 ) W 2 (d 1 ) F 1 (d 2 ) F 2 (d 1 ) L 2 (d 2 ) W 2 (d 2 ) D 1 freed after all locks gathered but before end of transaction 96 96

N ON T WO P HASE D IFFERENT O RDER T 1 T 2 T 1 T 2 W 1 (d 1 ) L 1 (d 1 ) W 2 (d 2 ) W 1 (d 1 ) L 2 (d 2 ) F 1 (d 1 ) W 2 (d 1 ) W 2 (d 2 ) F 2 (d 2 ) W 1 (d 2 ) L 1 (d 2 ) L 2 (d 1 ) W 1 (d 2 ) W 2 (d 1 ) F 1 (d 2 ) F 2 (d 1 ) 97

T WO -P HASE L OCKING D IFFERENT O RDER T 1 T 2 T 1 T 2 W 1 (d 1 ) L 1 (d 1 ) W 2 (d 2 ) W 1 (d 1 ) L 2 (d 2 ) L 1 (d 2 ) W 2 (d 1 ) W 2 (d 2 ) L 2 (d 1 ) W 1 (d 2 ) Non serializable schedules lead to deadlocks Two phase locking Need deadlock detection schemes A transaction has a growing phase when locks are added and not released Then it has a shrinking phase when 98 98 locks are released but not freed

P ROOF THAT 2PL  S ERIALIZABILITY Transaction graph: T 1 has edge to T 2 if T 2 performs some (non commuting) operation after some operation performed by T 1 Non-serializable == Cycles in transaction graph Cycles in transaction graph under 2PL will lead to deadlocks Proof by Contradiction There is a cycle but no deadlock Cycle: T 1 accessed d 1 before T 2 , and T 2 accessed d 2 before T 1 No deadlock: T 1 had both locks before T 2 had any locks (or vice versa) No deadlock: No cycle 99

L OCKING : O NE I TEM T 1 T 2 T 1 T 2 R 1 (d 1 ) L 1 (d 1 ) L 2 (d 1 ) R 1 (d 1 ) R 2 (d 1 ) W 2 (d 1 ) W 1 (d 1 ) W 1 (d 1 ) F 1 (d 1 ) R 2 (d 1 ) W 2 (d 1 ) F 1 (d 1 ) Single lock for read and write? T 2 ‘s read unnecessarily delayed 100 100