1. ICS 541 - 01 (072)Concurrency Control1 Transaction Processing and Concurrency Control Dr. Muhammad Shafique Chapter 18 17 March 2008

2. ICS 541 - 01 (072)Concurrency Control2 Outline Granularity of data items Concurrency control techniques Locking techniques Timestamp ordering techniques Multi-version concurrency control techniques Optimistic concurrency control techniques Advanced Concurrency control techniques Summary

3. ICS 541 - 01 (072)Concurrency Control3 Concurrency Control Techniques Categories of concurrency techniques 1.Locking techniques 2.Timestamp ordering techniques 3.Multi-version concurrency control techniques 4.Optimistic concurrency control techniques 5.Advanced concurrency control techniques

4. ICS 541 - 01 (072)Concurrency Control4 Granularity of Data Items Size or granule of data for concurrency control is data item granularity. It could be An attribute value A database record A disk block A whole file The whole database Data item granularity and degree of concurrency Fine granularity --- refers to small item sizes Coarse granularity --- refers to large item sizes Larger the data item size, lower the degree of concurrency Data item size depends on the types of transactions

5. ICS 541 - 01 (072)Concurrency Control5 Granularity of Data Items (Cont.) Multiple granularity levels and locking

6. ICS 541 - 01 (072)Concurrency Control6 Granularity of Data Items (Cont.) Multiple granularity levels and locking (cont.) Intension locks In addition to shared (S) and Exclusive (X) Intention-Shared (IS) Intention-Exclusive (IX) Shared-Intention- Exclusive (SIX) Locking compatibility

7. ICS 541 - 01 (072)Concurrency Control7 Concurrency Control Through Locks Lock A variable associated with a data item Describes status of the data item with respect to operations that can be performed on it Binary locks Locked/unlocked Enforces mutual exclusion Multiple-mode locks: Read lock or shared lock Write lock or exclusive lock Unlock Each data item can be in one of three lock states

8. ICS 541 - 01 (072)Concurrency Control8 Locking Rules 1.T must issue read_lock(X) or write_lock(X) before any read_item(X) operation is performed in T 2.T must issue write_lock(X) before any write_item(X) operation is performed in T 3.T must issue unlock(X) after all read_item(X) and write_item(X) operations are completed in T 4.T will not issue a read_lock(X) if it already holds a read lock or write lock on X (may be relaxed) 5.T will not issue a write_lock(X) if it already holds a read lock or write lock on X (may be relaxed) 6.T will not issue unlock (X) request unless it holds a read lock write lock on X

9. ICS 541 - 01 (072)Concurrency Control9 Two Transactions T1 read_lock(Y); read_item(Y); unlock(Y); write_lock(X); read_item(X); X:=X+Y; write_item(X); unlock(X); T2 read_lock(X); read_item(X); unlock(X); write_lock(Y); read_item(Y); Y:=X+Y; write_item(Y); unlock(Y); Let’s assume serial schedule S1: T1,T2 Initial values: X=20, Y=30  Result: X=50, Y=80

10. ICS 541 - 01 (072)Concurrency Control10 Locks Alone Don’t Insure Serializability T1 read_lock(Y); read_item(Y); unlock(Y); write_lock(X); read_item(X); X:=X+Y; write_item(X); unlock(X); T2 read_lock(X); read_item(X); unlock(X); write_lock(Y); read_item(Y); Y:=X+Y; write_item(Y); unlock(Y); Non-serializable! Result: X=50, Y=50 unlocked too early! Let’s run T1 and T2 in interleaved fashion Schedule S

11. ICS 541 - 01 (072)Concurrency Control11 Two-Phase Locking (2PL) Protocol Transaction is said to follow the two-phase-locking protocol if all locking operations precede the first unlock operation Expanding (growing) phase Shrinking phase During the shrinking phase no new locks can be acquired Downgrading ok Upgrading is not Example

12. ICS 541 - 01 (072)Concurrency Control12 2PL Example T1’ read_lock(Y); read_item(Y); write_lock(X); unlock(Y); read_item(X); X:=X+Y; write_item(X); unlock(X); T2’ read_lock(X); read_item(X); write_lock(Y); unlock(X); read_item(Y); Y:=X+Y; write_item(Y); unlock(Y); Both T1’ and T2’ follow the 2PL protocol Any schedule including T1’ and T2’ is guaranteed to be serializable Limits the amount of concurrency

13. ICS 541 - 01 (072)Concurrency Control13 Locking Techniques for Concurrency Control Quick review of ideas discussed so far Locks and system lock tables Lock table and lock manager Binary locks --- lock & unlock operations (critical sections) Shared/exclusive locks --- read-lock, write-lock, and unlock Conversion of locks Upgrade the lock Downgrade the lock Concurrency control subsystem generates read-lock and write-lock requests on behalf of the transactions Using locks in transactions does not guarantee serializability of schedules on its own

14. ICS 541 - 01 (072)Concurrency Control14 Using Locks for Concurrency Control in Indexes Two phase locking can be applied to indexes. Here the nodes of an index correspond to disk pages. Tree structure of the index can be taken advantage of A conservative approach for insertions can be to lock the root node in exclusive mode. Index locking using B-link tree rather than B+ tree In B-link tree, sibling nodes at the same level are linked together at every level

15. ICS 541 - 01 (072)Concurrency Control15 Locking Techniques for Concurrency Control (Cont.) Two-phase locking protocol (2PL) All lock operations precede the first unlock operation Expanding phase and shrinking phase Upgrading of locks must be done in expanding phase and downgrading of locks must be done in shrinking phase If every transaction in a schedule follows 2PL protocol then the schedules is guaranteed to be serializable. Variants of 2PL Basic, conservative, strict, and rigorous

16. ICS 541 - 01 (072)Concurrency Control16 Locking Techniques for Concurrency Control (Cont.) 1.Basic 2PL All lock operations before the first unlock operation 2.Conservative 2PL or static 2PL Lock all the items it accesses before the transaction begins execution. 1.Deadlock free protocol 2.Read-set and write-set of the transaction should be known 3.Strict 2PL No exclusive lock will be unlocked until the transaction commits or aborts Strict 2PL guarantees strict schedules 4.Rigorous 2PL No lock will be unlocked until the transaction commits or aborts

17. ICS 541 - 01 (072)Concurrency Control17 Dealing with Deadlocks and Starvation in 2PL 2PL can produce deadlocks Deadlock and starvation in 2PL Deadlock occurs when each transaction T in a set of two or more transactions is waiting for some item that is locked by some other transaction T’ in the set. Example (next slide)

18. ICS 541 - 01 (072)Concurrency Control18 Dealing with Deadlocks and Starvation in 2PL

19. ICS 541 - 01 (072)Concurrency Control19 Dealing with Deadlocks and Starvation in 2PL Deadlock prevention protocols Conservative 2PL, lock all needed items in advance Ordering all items in the database Possible actions if a transaction is involved in a possible deadlock situation Block and wait Abort and restart Preempt and abort another transaction

20. ICS 541 - 01 (072)Concurrency Control20 Dealing with Deadlocks and Starvation in 2PL Two schemes that prevent deadlock (Timestamp based) Wait-die An older transaction is allowed to wait on a younger transaction whereas a younger transaction requesting an item from held by an older transaction is aborted and restarted with the same timestamp Wound-wait A younger transaction is allowed to wait on an older transaction whereas an older transaction requesting an item from held by a younger transaction preempts the younger transaction by aborting it.

21. ICS 541 - 01 (072)Concurrency Control21 Dealing with Deadlocks and Starvation in 2PL Two schemes that prevent deadlock and do not require timestamps No waiting Abort immediately and restart after a certain time delay Cautious waiting If a transaction holding the lock is not waiting for another item to be locked then allow T to wait otherwise abort and restart T

22. ICS 541 - 01 (072)Concurrency Control22 Dealing with Deadlocks and Starvation in 2PL Deadlock detection and timeouts Construct and maintain a wait-for graph Victim selection Timeouts Starvation A transaction cannot proceed for an infinite period of time while other transactions in the system continue normally Unfair waiting scheme Victim selection

23. ICS 541 - 01 (072)Concurrency Control23 Concurrency Control Based on Timestamp Ordering Timestamp --- a unique identifier created by the DBMS to identify a transaction read-TS(X) The largest timestamp among all the timestamps of transactions that have successfully read item X write-TS(X) The largest timestamp among all the timestamps of transactions that have successfully written item X Timestamp Ordering (TO) algorithms Basic timestamp ordering Strict timestamp ordering Thomas’s write rule

24. ICS 541 - 01 (072)Concurrency Control24 Concurrency Control Based on Timestamp Ordering (Cont.) Basic timestamp ordering algorithm Order transactions based on their timestamps 1.T issues a write(X) 1.If read-TS(X) > TS(T) or if write-TS(X) > TS(T) the abort and rollback T and reject the operation. 2.If condition above does not occur then execute the operation and set write-TS(X) = TS(T) 2.T issues a read(X) 1.If write-TS(X) > TS(T) then abort and rollback T and reject the operation. 2.If write-TS(X)  TS(T) then execute the operation and set read-TS(X) = max ( read-TS(X), TS(T) ) The schedules produced by basic TO are guaranteed to be conflict serializable No deadlocks but cyclic restart are possible (hence starvation)

25. ICS 541 - 01 (072)Concurrency Control25 Concurrency Control Based on Timestamp Ordering (Cont.) Strict Timestamp Ordering (strict TO) A transaction T that issues a read-item(X) or write-item(X) such that TS(T) > write-TS(X) has its read or write operation delayed until the transaction T’ that wrote the value of X (hence TS(T’ ) = write-TS(X)) has committed or aborted. No deadlocks, since T waits for T’ only if TS(T) > TS(T’) Strict TO ensures that the schedules are both strict (for easy recoverability) and (conflict) serializable

26. ICS 541 - 01 (072)Concurrency Control26 Concurrency Control Based on Timestamp Ordering (Cont.) Thomas’s write rule It rejects fewer write operations, by modifying the basic TO checks for the write-item(X) operation as follows: 1.If read-TS(X) > TS(T), then abort and roll back T and reject the operation. 2.If write-TS(X) > TS(T), then do not execute the write operation but continue processing. [ This is because some transaction with timestamp greater than TS(T)—and hence after T in the timestamp ordering—has already written the value of X. Hence, we must ignore the write_item(X) operation of T because it is already outdated and obsolete. Notice that any conflict arising from this situation would be detected by case (1).] 3.If neither the condition in part (1) nor the condition in part (2) occurs, then execute the write-item(X) operation of T and set write- TS(X) to TS(T). Thomas’ write rule does not enforce conflict serializability

27. ICS 541 - 01 (072)Concurrency Control27 Multi-version Concurrency Control Techniques Several versions X 1, X 2,..., X k of each data item X are maintained Multi-version Technique based on timestamp ordering To ensure serializability, the following two rules are used 1.If transaction T issues a write(X) operation, and version i of x has the highest write-TS(X i ) of all versions of X that is also less than or equal to TS(T), and read-TS(X i ) > TS(T), then abort and rollback T; otherwise create a new version X j of x with read-TS(X j ) = write-TS(X j ) =TS(T) 2.If transaction T issues a read(X) operation, find version i of x that has the highest write-TS(X i ) of all versions of X that is also less than or equal to TS(T), then return the value of X j to transaction T, and set the value of read-TS(X j ) to the larger of TS(T) and the current read- TS(X j )

28. ICS 541 - 01 (072)Concurrency Control28 Multi-version Concurrency Control Techniques Multi-version 2PL using certify locks Three locking modes: read, write, and certify Two versions of each item X; one version must have been written by some committed transaction and the second version is created when a transaction acquires a write lock on X A transaction must acquire a certify lock on all items that it currently holds write locks on before it can commit The scheme avoids cascading aborts

29. ICS 541 - 01 (072)Concurrency Control29 Optimistic Concurrency Control Techniques Optimistic concurrency control techniques also known as validation concurrency control techniques or certification concurrency control techniques No checking is done while the transaction is executing Updates in the transaction are not applied directly to the database until the transaction reaches its end There are three phases 1.Read phase --- a transaction can read values of committed data items from the database. Updates are applied only to the local copies of the data items 2.Validation phase --- Checking is performed to ensure that serializability will not be violated if the transaction updates are applied to the database. 3.Write phase --- if the validation phase is successful, the transaction updates are applied to the data base otherwise the updates are discarded and the transaction restarted.

30. ICS 541 - 01 (072)Concurrency Control30 Optimistic Concurrency Control Techniques Validation phase Timestamp Read-set and write-set of a transaction Start and end time for each of the three phases of a transaction Mutual exclusiveness For transaction T i the protocol checks that T i does not interfere with any committed transaction or with a transaction in validation phase, i.e., 1.T j completes its write phase before T i starts its read phase 2.T i starts its write phase after T j completes its write phase and intersection of read-set of T i and write-sets of T j is empty 3.Both the read-set and write set of T i have no items in common with the write-set of T j and T j completes its read phase before T i completes its read phase.

31. ICS 541 - 01 (072)Concurrency Control31 Other Concurrency Control Issues Insertion, deletion, and phantom records Insertion operation New data item inserted in the database Deletion operation Phantom record Use index locking Interactive transactions No rollback Delay output of transactions until they have committed Latches Locks held for a short duration are called latches Latches are used to, for example, write a buffer to a page

32. ICS 541 - 01 (072)Concurrency Control32 Summary Granularity of data items Concurrency control techniques Locking techniques Timestamp ordering techniques Multi-version concurrency control techniques Optimistic concurrency control techniques Other concurrency control issues Thank you