1. 1 Concurrency Control

2. 2 Locking: A Technique for C. C. Concurrency control usually done via locking. Lock info maintained by a “lock manager”: –Stores (XID, RID, Mode) triples. This is a simplistic view; suffices for now. –Mode  {S,X} –Lock compatibility table: If a Xact can’t get a lock, it is suspended on a wait queue. -- SX S X     

3. 3 Two-Phase Locking (2PL) 2PL: –If T wants to read an object, first obtains an S lock. –If T wants to modify an object, first obtains X lock. –If T releases any lock, it can acquire no new locks! Locks are automatically obtained by DBMS. Guarantees serializability! –Why? Time # of locks lock point growing phase shrinking phase

4. 4 Strict 2PL Strict 2PL: –If T wants to read an object, first obtains an S lock. –If T wants to modify an object, first obtains X lock. –Hold all locks until end of transaction. Guarantees serializability, and recoverable schedule, too! –also avoids WW problems! Time # of locks

5. 5 Lock Management Lock and unlock requests are handled by the lock manager Lock table entry: – Number of transactions currently holding a lock – Type of lock held (shared or exclusive) – Pointer to queue of lock requests Locking and unlocking have to be atomic operations Lock upgrade: transaction that holds a shared lock can be upgraded to hold an exclusive lock

6. 6 Lock Manager Implementation Question 1: What are we locking? –Tuples, pages, or tables? –Finer granularity increases concurrency, but also increases locking overhead. Question 2: How do you “lock” something?? Lock Table: A hash table of Lock Entries. –Lock Entry: OID Mode List: Xacts holding lock List: Wait Queue

7. 7 Handling a Lock Request Lock Request (XID, OID, Mode) Currently Locked? Grant Lock Empty Wait Queue? Currently X-locked? Mode==X Mode==S No Yes No Yes Put on Queue Yes No

8. 8 More Lock Manager Logic On lock release (OID, XID): –Update list of Xacts holding lock. –Examine head of wait queue. –If Xact there can run, add it to list of Xacts holding lock (change mode as needed). –Repeat until head of wait queue cannot be run. Note: Lock request handled atomically! –via latches (i.e. semaphores/mutex; OS stuff).

9. 9 Lock Upgrades Think about this scenario: –T1 locks A in S mode, T2 requests X lock on A, T3 requests S lock on A. What should we do? In contrast: –T1 locks A in S mode, T2 requests X lock on A, T1 requests X lock on A. What should we do? Allow such upgrades to supersede lock requests. –Consider this scenario: S1(A), X2(A), X1(A): DEADLOCK! BTW: Deadlock can occur even w/o upgrades: –X1(A), X2(B), S1(B), S2(A)

10. 10 Deadlocks Deadlock: Cycle of transactions waiting for locks to be released by each other. Two ways of dealing with deadlocks: – Deadlock prevention – Deadlock detection

11. 11 Deadlock Prevention Assign a timestamp to each Xact as it enters the system. “Older” Xacts have priority. Assume Ti requests a lock, but Tj holds a conflicting lock. –Wait-Die: If Ti has higher priority, it waits; else Ti aborts. (non-preemptive) –Wound-Wait: If Ti has higher priority, abort Tj; else Ti waits. (preemptive) –Note: After abort, restart with original timestamp! –Both guarantee deadlock-free behavior! Pros and cons of each? X1(A), X2(B), S1(B), S2(A)

12. 12 Deadlock Detection Create a waits-for graph: – Nodes are transactions – There is an edge from Ti to Tj if Ti is waiting for Tj to release a lock Periodically check for cycles in the waits-for graph. “Shoot” some Xact to break the cycle. Simpler hack: time-outs. –T1 made no progress for a while? Shoot it.

13. 13 Deadlock Detection (Continued) Example: T1: S(A), R(A), S(B) T2: X(B),W(B) X(C) T3: S(C), R(C) X(A) T4: X(B) T1T2 T4T3 T1T2 T3

14. 14 Prevention vs. Detection Prevention might abort too many Xacts. Detection might allow deadlocks to tie up resources for a while. –Can detect more often, but it’s time-consuming. The usual answer: –Detection is the winner. –Deadlocks are pretty rare. –If you get a lot of deadlocks, reconsider your schema/workload!

15. 15 Multiple-Granularity Locks Hard to decide what granularity to lock (tuples vs. pages vs. tables). Shouldn’t have to decide! Data “containers” are nested: Tuples Tables Pages Database contains

16. 16 Solution: New Lock Modes, Protocol Allow Xacts to lock at each level, but with a special protocol using new “intention” locks: v Before locking an item, Xact must set “intention locks” on all its ancestors. v For unlock, go from specific to general (i.e., bottom-up). v SIX mode: Like S & IX at the same time. -- ISIX -- IS IX      SX   S X      

17. 17 Multiple Granularity Lock Protocol Each Xact starts from the root of the hierarchy. To get S or IS lock on a node, must hold IS or IX on parent node. –What if Xact holds SIX on parent? S on parent? To get X or IX or SIX on a node, must hold IX or SIX on parent node. Must release locks in bottom-up order. Protocol is correct in that it is equivalent to directly setting locks at the leaf levels of the hierarchy.

18. 18 Examples T1 scans R, and updates a few tuples: –T1 gets an SIX lock on R, then repeatedly gets an S lock on tuples of R, and occasionally upgrades to X on the tuples. T2 uses an index to read only part of R: –T2 gets an IS lock on R, and repeatedly gets an S lock on tuples of R. T3 reads all of R: –T3 gets an S lock on R. –OR, T3 could behave like T2; can use lock escalation to decide which. -- ISIX -- IS IX      SX   S X      

19. 19 Timestamp CC Idea: Give each object a read-timestamp (RTS) and a write-timestamp (WTS), give each Xact a timestamp (TS) when it begins: –If action ai of Xact Ti conflicts with action aj of Xact Tj, and TS(Ti) < TS(Tj), then ai must occur before aj. Otherwise, restart violating Xact.

20. 20 Timestamp-Ordering Protocol Timestamp order equals to serialization order Ensure conflict serializability TS(T i ) < TS(T j ) implies T i runs before T j in a serial schedule Each data item Q have two timestamps –WTS(Q): the largest timestamp of any transaction that successfully executed write(Q) –RTS(Q): the largest timestamp of any transaction successfully executed read(Q)

21. 21 When Xact T wants to read Object O If TS(T) < WTS(O), this violates timestamp order of T w.r.t. writer of O. –So, abort T and restart it with a new, larger TS. (If restarted with same TS, T will fail again! Contrast use of timestamps in 2PL for ddlk prevention.) If TS(T) > WTS(O): –Allow T to read O. –Reset RTS(O) to max(RTS(O), TS(T)) Change to RTS(O) on reads must be written to disk! This and restarts represent overheads.

22. 22 When Xact T wants to Write Object O If TS(T) < RTS(O), this violates timestamp order of T w.r.t. writer of O; abort and restart T. If TS(T) < WTS(O), violates timestamp order of T w.r.t. writer of O. –Thomas Write Rule: We can safely ignore such outdated writes; need not restart T! (T’s write is effectively followed by another write, with no intervening reads.) Allows some serializable but non conflict serializable schedules: Else, allow T to write O. T1 T2 R(A) W(A) Commit W(A) Commit

23. 23 Timestamp-Ordering Protocol Consider the following history: r 1 [x], r 2 [x], w 2 [x], r 1 [y], r 2 [y] Let TS(T 1 ) and TS(T 2 ) be 1 and 2 respectively. Show that the above history can be accepted by the timestamp-ordering protocol Ans: Assume the initial timestamp of x and y = 0, consider each of the cases: –r 1 [x]: Since TS(T 1 )≥W-timestamp(x), read is executed and R-timestamp(x)=1 –r 2 [x]: Since TS(T 2 )≥W-timestamp(x), read is executed and R-timestamp(x)=2 –w 2 [x]: Since TS(T 2 )≥W-timestamp(x) and TS(T 2 )≥R-timestamp(x), write is executed and W-timestamp(x)=2 –r 1 [y]: Since TS(T 1 )≥W-timestamp(y), read is executed and R-timestamp(y)=1 –r 2 [y]: Since TS(T 2 )≥W-timestamp(y), read is executed and R-timestamp(y)=2

24. 24 Timestamp CC and Recoverability Timestamp CC can be modified to allow only recoverable schedules: –Buffer all writes until writer commits (but update WTS(O) when the write is allowed.) –Block readers T (where TS(T) > WTS(O)) until writer of O commits. Similar to writers holding X locks until commit, but still not quite 2PL. T1 T2 W(A) R(A) W(B) Commit v Unfortunately, unrecoverable schedules are allowed:

25. 25 Exercise Suppose that initially the read-timestamp of data item X is 25 and the write timestamp of X is 20. If [r,t] (respectively [w,t]) denotes a read (write) operation on X by any transaction with timestamp t, describe the behavior of Basic Timestamp Ordering on the following sequence of operations: [r,19], [r,22], [w,21], [w,26], [r,28], [w,27], [w,32], [w,31]

26. 26 Exercise Determine whether each of following executions is serializable or not. For each serializable execution, give the serial schedule which is equivalent to the given schedule. 1.R1(X), W2(X), W1(X), R2(Y) 2.R1(X), W2(X), W3(X), R1(X) 3.R1(X), W2(X), W3(Y), W1(Y)

27. 27 Exercise Transactions T1, T2, T3 are to be run concurrently. The following gives details of the proposed interleaving of read/write operations and the time when each such operation is to be scheduled. TimeT1T2T3 1read(A) 2read(A) 3read(D) 4write(D) 5write(A) 6read(C) 7 write(B) 8 write(B) Determine whether the operations can be executed in this order if concurrency is to be controlled using –two-phase locking –timestamp ordering