Chapter 16 Concurrency Control CS157b Tom Mensch

Motivation: Bank Example zOne bank account with $100 balance zTwo different ATMs both trying to withdraw $100 from the same account at exactly the same time zBoth ATMs check the balance of the account and see it’s $100

Bank Example Continued zSince the balance is enough, both ATMs give out $100 zAfter both transactions complete the balance is -$100 zOne of the transactions should have been denied

Concurrent Transactions zProblem: How can data be accessed by multiple transactions without compromising data integrity? zSolution: Only allow a transaction to access data if it holds a “lock” on it.

Transactions with Locking zBoth ATMs try to “lock” the account zOne succeeds and withdraws $100 zThe second ATM has to wait until the first ATM releases it’s lock before it can proceed z Now when the second ATM tries to withdraw the $100 it cannot because the balance is $0

Locks zShared - transaction wants read access to data. zExclusive - transaction wants both read and write access to data.

shared-mode lock zMultiple transactions can have shared- mode locks on the same data. zEx: Transaction T1 has shared-mode lock on data A. Transaction T2 requests a shared-mode lock on data A; the request is granted.

exclusive-mode lock zOnly one transaction can have an exclusive-mode lock on a data item. zEx: Transaction T1 has exclusive-mode lock on data A. Transaction T2 requests a exclusive-mode lock on data A; the request is denied.

Lock-compatibility zShared - other shared-mode lock requests granted. zExclusive - all other lock requests denied.

Unlocking data zTransaction must unlock data when done accessing it. zShared-mode locks wait for exclusive- mode locks to be released zExclusive-mode locks wait for all other locks be be released

Indefinite postponement? zCan an exclusive-mode lock be indefinitely postponed (starved) by an infinite number of shared-mode lock requests? zNo. Because the concurrency-control manager will make shared-mode requests wait if an exclusive-mode is already waiting for a shared-mode lock to be released.

Balance Transfer Example zBank account A has a $100 balance zBank account B has a $200 balance zTransaction T1 transfers $50 from account B to account A zT1 locks A, withdraws $50 and unlocks A zT1 then locks B, adds $50 and unlocks B

Bank Transfer Continued zTransaction T2 wants to find out the sum of the balances of accounts A and B zT2 asks for a lock on both accounts after T1 has released it’s lock on A but before T1 locks B zT1 must now wait for T2 to complete before adding the $50 to account A

Bank Transfer Continued zThe result of T2 is $250 which is incorrect zWhy? zT1 should have held it’s lock on A longer

Deadlocks zT1 requests exclusive lock on A. Granted zT2 requests exclusive lock on B. Granted zT1 requests exclusive lock on B. Wait zT2 requests exclusive lock on A. Wait

Deadlocks Continued zT2 will never release it’s lock on B until it gets a lock on A zT1 will never release it’s lock on A until it gets a lock on B zBoth transactions will wait forever zThis is bad

Two-Phase Locking Protocol z1. Growing phase - transactions may acquire new locks z2. Shrinking phase - transactions may release locks, but not acquire new ones

Two-Phase Locking Continued zStrict two-phase locking protocol - requires that all exclusive locks be held until the transaction commits zRigorous two-phase locking protocol - requires that all locks be held until the transaction commits

Timestamp-Based protocols zEach transaction gets a timestamp when it enters the system zTimestamp can be either the system time, or simply a logical counter zW-timestamp(Q) - largest timestamp of any transaction that did write(Q) successfully zR-timestamp(Q) - largest timestamp of any transaction that did read(Q) successfully

Timestamp-Ordering zTransaction Ti with timestamp TS(Ti) issues read(Q) zTS(Ti) < W-timestamp(Q) then read(Q) is rejected and Ti is rolled back zTS(Ti) >= W-timestamp(Q) then read(Q) executes successfully

Timestamp-Ordering Cont. zTransaction Ti with timestamp TS(Ti) issues write(Q) zTS(Ti) < R-timestamp(Q) then write(Q) is rejected and Ti is rolled back zTS(Ti) < W-timestamp(Q) then write(Q) is rejected and Ti is rolled back zOtherwise write(Q) executes successfully

Thomas’ Write Rule zTransaction Ti with timestamp TS(Ti) issues write(Q) zTS(Ti) < R-timestamp(Q) then write(Q) is rejected and Ti is rolled back zTS(Ti) < W-timestamp(Q) then write(Q) is ignored and Ti continues zOtherwise write(Q) executes successfully

Validation-Based Protocols zConcurrency-control schemes impose additional overhead on system and can cause delays zSolution: find conflicts before they happen

Three-phase execution zRead phase - transaction reads data zValidation phase - transaction makes sure none of it’s writes to it’s temporary variables conflict with other operations zWrite phase - apply actual changes to database

Validation timestamps zValidation requires three timestamps zStart - time the transaction began executing zValidation - time the Read phase competed and Validation phase began zFinish - time the transaction completed