1. 2015-10-251 CONCURRENCY CONTROL (CHAPTER 16)

2. 2015-10-252 CONCURRENCY CONTROL INTRODUCTION Motivation: A dbms is multiprogrammed to increase the utilization of resources. While the CPU is processing one transaction, the disk can perform a write operation on behalf of another transaction. However, the interaction between multiple transactions must be controlled to ensure atomicity and consistency of the database. As an example, consider the following two transactions. T 0 transfers 50 from account A to B. T 1 transfers 10% of the balance from A to B. –T 0 T 1 read(A) A=A-50 tmp = A × 0.1 write(A) A = A - tmp read(B) write(A) B=B+50 read(B) write(B) B=B+tmp write(B)

3. 2015-10-253 CONCURRENCY CONTROL INTRODUCTION (Cont…) Assume the balance of A is 1000 and B is 2000. The bank's total balance is 3000. If the system executes T 0 before T 1 then A's balance will be 855 while B's balance will be 2145. On the other hand, if T 1 executes before T 0 then A's balance will be 850 and B's balance will be 2150. However, note that in both cases, the total balance of these two accounts is 3000. In this example both schedules are consistent. T 0 T 1 read(A) A=A-50 tmp = A × 0.1 write(A) A = A - tmp read(B) write(A) B=B+50 read(B) write(B) B=B+tmp write(B) A schedule is a chronological execution order of multiple transactions by a system. A serial schedule is a sequence of processing multiple transactions which ensures atomicity of each transaction. Given n transactions, there are n! valid serial schedules.

4. Schedule 1 Let T 1 transfer $50 from A to B, and T 2 transfer 10% of the balance from A to B. A serial schedule in which T 1 is followed by T 2 :

5. Schedule 2 A serial schedule where T 2 is followed by T 1

6. 2015-10-256 Concurrent execution of multiple transactions, where the instructions of different transactions are interleaved, may result in a non-serial schedule. To illustrate, assuming that a transaction makes a copy of each data item in order to manipulate it, consider the following execution: t1 t2 Time A B A B

7. Schedule 3 Let T 1 and T 2 be the transactions defined previously. The following schedule is not a serial schedule, but it is equivalent to Schedule 1. In Schedules 1, 2 and 3, the sum A + B is preserved.

8. Schedule 4 The following concurrent schedule does not preserve the value of (A + B).

9. Serializability Basic Assumption – Each transaction preserves database consistency. Thus serial execution of a set of transactions preserves database consistency. A (possibly concurrent) schedule is serializable if it is equivalent to a serial schedule We ignore operations other than read and write instructions, and we assume that transactions may perform arbitrary computations on data in local buffers in between reads and writes. Our simplified schedules consist of only read and write instructions.

10. Conflicting Instructions Instructions l i and l j of transactions T i and T j respectively, conflict if and only if there exists some item Q accessed by both l i and l j, and at least one of these instructions wrote Q. 1. l i = read(Q), l j = read(Q). l i and l j don’t conflict. 2. l i = read(Q), l j = write(Q). They conflict. 3. l i = write(Q), l j = read(Q). They conflict 4. l i = write(Q), l j = write(Q). They conflict Intuitively, a conflict between l i and l j forces a (logical) temporal order between them. –If l i and l j are consecutive in a schedule and they do not conflict, their results would remain the same even if they had been interchanged in the schedule.

11. Conflict Serializability If a schedule S can be transformed into a schedule S´ by a series of swaps of non-conflicting instructions, we say that S and S´ are conflict equivalent. We say that a schedule S is conflict serializable if it is conflict equivalent to a serial schedule

12. Schedule 3 Looking only at Read(Q) and write(Q) instructions Schedule 3 can be transformed into a new schedule, a serial schedule where T 2 follows T 1, by series of swaps of non-conflicting instructions.

13. Schedule 3 2015-10-2513 T1T2 Read(A) Write(A) Read(B) Write(B) Read(A) Write(A) Read(B) Write(A)

14. 2015-10-2514 LOCK-BASED PROTOCOLS There are alternative approaches to ensure serializability among multiple transactions. Lock-based Protocols To ensure serializability, require access to data items to be performed in a mutually exclusive manner. This approach requires a transaction to lock a data item before accessing it. The simple protocol consists of two lock modes: Shared and eXclusive. A transaction locks a data item Q in S mode if it plans to read Q's value and X mode it it plans to write Q. The compatibility between these two lock modes is as follows: SX STrueFalse X T1T1 T0T0 shared (S) mode. Data item can only be read. S-lock is requested using lock-S instruction. exclusive (X) mode. Data item can be both read as well as written. X-lock is requested using lock-X instruction. Lock requests are made to concurrency-control manager. Transaction can proceed only after request is granted.

15. 2015-10-2515 LOCK-BASED PROTOCOLS (Cont…) There can be multiple transactions with S locks on a particular data item. However, only one X lock is allowed on a data item. When a transaction requests a lock, if a compatible lock mode exists, it proceeds to lock the data item. Otherwise, it waits. Waiting might result in deadlocks.

16. 2015-10-2516 CONCURRENCY CONTROL INTRODUCTION (Cont…) T 0 T 1lockX(A) read(A) A=A-50 tmp = A × 0.1 write(A) A = A - tmp unlock(A) write(A) lockX(B) unlock(A) read(B) lockX(B) B=B+50 read(B) write(B) B=B+tmp unlock(B) write(B) unlock(B) 2 4 1 3

17. 2015-10-2517 LOCK-BASED PROTOCOLS (Cont…) T 0 T 1 lockX(A) read(A) A=A-50 write(A) lockX(B) read(B) tmp = B × 0.1 B = B - tmp write(B) lockX(B) lockX(A) DEADLOCK read(B) B=B+50 write(B) read(A) A=A+tmp write(A)

18. 2015-10-2518 LOCK-BASED PROTOCOLS (Cont…) As a solution to deadlocks, most systems construct a Transaction Wait for Graph (TWG). A transaction is represented as a node in TWG. When a transaction T i waits for T j, an arc is attached from T i to T j. Next, the system detects cycles in the TWG. If a cycle is detected then there exists a deadlock. The system breaks deadlocks by aborting one of the transactions (e.g., using log-based recovery protocol). Deadlocks can be described as a wait-for graph, which consists of a pair G = (V,E), V is a set of vertices (all the transactions in the system) E is a set of edges; each element is an ordered pair Ti  Tj.

19. 2015-10-2519 Deadlock Detection (Cont.) Wait-for graph without a cycle Wait-for graph with a cycle

20. 2015-10-2520 Example: suppose the values of account A and B are 100 & 200 If T1 and T2 are executed Serially, what is displayed T1T2 lockX(B) read(B) B=B-50 write(B) unlock(B) lock-X(A) read(A) A=A+50 write(A) unlock(A) lockS(A) read(A) unlock(A) lockS(B) read(B) unlock(B) display(A+B)

21. 2015-10-2521 Example: suppose the values of account A and B are 100 & 200 If T1 and T2 are executed concurrently, what is displayed T1T2 lockX(B) read(B) B=B-50 write(B) unlock(B) lock-X(A) read(A) A=A+50 write(A) unlock(A) lockS(A) read(A) unlock(A) lockS(B) read(B) unlock(B) display(A+B)

22. 2015-10-2522 Example: suppose the values of account A and B are 100 & 200 If T1 and T2 are executed concurrently, what is displayed T1T2 lockX(B) read(B) B=B-50 write(B) lock-X(A) read(A) A=A+50 write(A) unlock(B) unlock(A) lockS(A) read(A) lockS(B) read(B) unlock(A) unlock(B) display(A+B)

23. 2015-10-2523 LOCK-BASED PROTOCOLS (Cont…) With a two phase locking protocol, each transaction is required to release its locks at the end of its execution. Thus, a transaction has two phases: 1.growing phase: the transaction acquires locks. But may not release any locks 2.shrinking phase: the transaction releases locks and acquires no additional locks

24. 2015-10-2524 LOCK-BASED PROTOCOLS (Cont…) Number of locks growingshrinking Lock point Time Lifetime of a transaction

25. 2015-10-2525 The Two-Phase Locking Protocol (Cont.) Two-phase locking does not ensure freedom from deadlocks Cascading roll-back is possible under two-phase locking. To avoid this, follow a modified protocol called strict two-phase locking. Here a transaction must hold all its exclusive locks till it commits/aborts. Rigorous two-phase locking is even stricter: here all locks are held till commit/abort. In this protocol transactions can be serialized in the order in which they commit. When a single transaction failure leads to a series of transaction rollbacks T1T2T3 lockX(A) Read(A) lockS(B) Read(B) Write(A) Unlock(A) lockX(A) Read(A) Write(A) Unlock(A) lockS(A) Read(A) T1 fails, rollback T2&T3 T3T4T3T4 lockX(B) read(B) B=B-50 write(B) lockX(A) A=A+50 write(A) unlock(B) unlock(A) lockS(A) read(A) lockS(B) read(B) display(A+B) unlock(A) unlock(B) lockX(B) read(B) B+B-50 write(B) lockX(A) lockS(A) read(A) lockS(B)

26. 2015-10-2526 The Two-Phase Locking Protocol (Cont.) Two-phase locking does not ensure freedom from deadlocks Cascading roll-back is possible under two-phase locking. To avoid this, follow a modified protocol called strict two-phase locking. Here a transaction must hold all its exclusive locks till it commits/aborts. Rigorous two-phase locking is even stricter: here all locks are held till commit/abort. In this protocol transactions can be serialized in the order in which they commit.

27. 2015-10-2527 Lock Conversions Two-phase locking with lock conversions: – First Phase: –can acquire a lock-S on item –can acquire a lock-X on item –can convert a lock-S to a lock-X (upgrade) – Second Phase: –can release a lock-S –can release a lock-X –can convert a lock-X to a lock-S (downgrade) This protocol assures serializability. But still relies on the programmer to insert the various locking instructions.

28. 2015-10-2528 Automatic Acquisition of Locks A transaction T i issues the standard read/write instruction, without explicit locking calls. The operation read(D) is processed as: if T i has a lock on D then read(D) else begin if necessary wait until no other transaction has a lock-X on D grant T i a lock-S on D; read(D) end

29. 2015-10-2529 Automatic Acquisition of Locks (Cont.) write(D) is processed as: if T i has a lock-X on D then write(D) else begin if necessary wait until no other trans. has any lock on D, if T i has a lock-S on D then upgrade lock on D to lock-X else grant T i a lock-X on D write(D) end; All locks are released after commit or abort

30. 2015-10-2530 LOCK-BASED PROTOCOLS (Cont…) Without a two-phase locking protocol, the schedule provided by an execution of transactions might no longer be serializable. This is specially true in the presence of aborts. Several possible situations might arise: 1.dirty reads: A transaction T 0 reads the value of a record Q at two different points in time (t i and t j ) and observes a different value for this record. This is because an updating transaction T 1 produced the value of Q when T 0 read this value at time t i. However, T 1 aborted sometimes later (prior to t j ) and when T 0 tried to read the value of Q at t j, it observes the value of Q prior to execution of T 1. 2.un-repeatable reads: A transaction T 0 reads the value of a record Q at two different points in time (t i and t j ) and observes a different value for this record. After T 0 reads the value of Q at time t i, an updating transaction T 1 updates the value of Q and commits prior to t j. When T 0 read this value of Q at time t j, it observes a Different value for Q.

31. 2015-10-2531 LOCK-BASED PROTOCOLS (Cont…) Example of dirty reads: Example of unrepeatable reads: T 1 T 0 lockX(Q) lockS(Q) read(Q) Q=Q+50 unlock(Q) write(Q)lockX(Q) unlock(Q)Q=Q+50 read(Q)write(Q) unlock(Q) abortcommit lockS(Q) read(Q) read(Q) unlock(Q) time

32. 2015-10-2532 LOCK-BASED PROTOCOLS (Cont…) 3.dirty writes (lost updates): T 0 and T 1 read the value of Q at two different points in time and produce a new value for this data item. Subsequently, they overwrite each other when updating Q. The execution paradigm that motivated the use of locking (earlier in the lecture notes) is an example of dirty writes. T 0 T 1 read(A) A=950 A=A-50 read(A) A=1000 tmp = A × 0.1 tmp=100 A = A - tmp write(A) A=900 read(B) B=2000 A=950 write(A) B=2000 read(B) B=B+50 B=2050 write(B) B=B+tmp write(B) B=2100

33. 2015-10-2533 Most systems support four levels of lock granularities: –Level 3: locks held to end of a transaction (two phase locking that results in serializable schedules) –Level 2: write locks held to end of a transaction (un-repeatable reads) –Level 1: no read locks at all (dirty reads and un-repeatable reads) –Level 0: no locks (dirty writes, dirty reads and un-repeatable reads)

34. 2015-10-2534 Multiple Granularity Allow data items to be of various sizes and define a hierarchy of data granularities, where the small granularities are nested within larger ones Can be represented graphically as a tree When a transaction locks a node in the tree explicitly, it implicitly locks all the node's descendents in the same mode. Granularity of locking (level in tree where locking is done): –fine granularity (lower in tree): high concurrency, high locking overhead –coarse granularity (higher in tree): low locking overhead, low concurrency

35. 2015-10-2535 Example of Granularity Hierarchy The highest level in the example hierarchy is the entire database. The levels below are of type file, pages and record in that order.

36. 2015-10-2536 Intention Lock Modes In addition to S and X lock modes, there are three additional lock modes with multiple granularity: –intention-shared (IS): indicates explicit locking at a lower level of the tree but only with shared locks. –intention-exclusive (IX): indicates explicit locking at a lower level with exclusive locks –shared and intention-exclusive (SIX): the subtree rooted by that node is locked explicitly in shared mode and explicit locking is being done at a lower level with exclusive-mode locks. intention locks allow a higher level node to be locked in S or X mode without having to check all descendent nodes.

37. 2015-10-2537 Compatibility Matrix with Intention Lock Modes The compatibility matrix for all lock modes is: IS IX S S IX X IS IX S S IX X         

38. 2015-10-2538 Multiple Granularity Locking Scheme Transaction T i can lock a node Q, using the following rules: 1. The lock compatibility matrix must be observed. 2. The root of the tree must be locked first, and may be locked in any mode. 3. A node Q can be locked by T i in S or IS mode only if the parent of Q is currently locked by T i in IS mode. 4. A node Q can be locked by T i in X, SIX, or IX mode only if the parent of Q is currently locked by T i in either IX or SIX mode. 5. T i can lock a node only if it has not previously unlocked any node (that is, T i is two-phase). 6. T i can unlock a node Q only if none of the children of Q are currently locked by T i. Observe that locks are acquired in root-to-leaf order, whereas they are released in leaf-to-root order.

39. 2015-10-2539 1) T1 wants to update records r111 and r211 2) T2 wants to update all records on page p12 3) T3 wants to read record r11j and the entire f2 file

40. 2015-10-2540 TIME STAMP BASED PROTOCOL We saw locking: S, X, IS, IX, SIX Now, we will cover: –Time-stamp based protocols –Optimistic concurency control Time-stamp based protocol provide a mechanism to enforce order. How? When a transaction T i is submitted, we associate a unique fixed time stamp TS(T i ). No two transactions may have an identical time stamp. One way to realize this is to use the system clock. The time stamp of the transaction determines the serializability order. Associated with each data item Q is two time stamp values: –W-TimeStamp(Q): Largest time stamp of the transaction that has written Q to date –R-TimeStamp(Q): Largest time stamp of the transaction that has read Q to date

41. 2015-10-2541 TIME STAMP BASED PROTOCOL (Cont…) Lets assume that TS(T i ) is produced in an increasing order, i.e., T i < T i +1 Suppose transaction T i issues read(Q): –If TS(T i ) < W-TimeStamp(Q) then T i needs to read the value of Q which was already overwritten. Hence the read request is rejected and T i is rolled back. –If TS(T i ) >= W-TimeStamp(Q) then the read operation is executed and the R- timeStamp(Q) is set to the maximum of R-TimeStamp(Q) and TS(T i ). Suppose transaction T i issues write(Q): –If TS(T i ) < R-TimeStamp(Q) then this implies that some transaction has already consumed the value of Q and T i should have produced a value before that transaction read it. Thus, the write request is rejected and T i is rolled back. –If TS(T i ) < W-TimeStamp(Q) then T i is trying to write an obsolete value of Q. Hence reject T i ’s request and roll it back. –Otherwise, execute the write(Q) operation. When a transaction is rolled back, the system may assign a new timestamp to the transaction and restart its execution (as if it was just submitted). This approach is free from deadlocks.

42. 2015-10-2542 THOMAS’S WRITE RULE Consider the following schedule The rollback of T 2 is un-necessary because T 3 has already produced the final value. The right thing to do is to ignore the write operation performed by T 2. To accomplish this, modify the protocol for the write operation as follows (the protocol for read stays the same as before): When T i issues write(Q); –If TS(T i ) < R-TimeStamp(Q) then the value of Q that T i is producing was previously read. Hence, reject the write operation and roll T i back. –If TS(T i ) < W-TimeStamp(Q) then T i is writing an obsolete value of Q. Ignore this write operation. –Otherwise, the write is executed, and W-TimeStamp(Q) is set to TS(T i ) T2T2 T3T3 Read(Q) Write(Q) T 2 is aborted TIMETIME

43. 2015-10-2543 OPTIMISTIC CC (VALIDATION TECHNIQUE) Argues that the overhead of locking is too high and not worthwhile for applications whose workload consists of read-only transactions. Each transaction T i has three phases: –Read phase: reads the value of data items and copies its contents to variables local to T i. All writes are performed on the temporary local variables. –Validation phase: T i determines whether the local variables whose values have been overwritten can be copied to the database. If not then abort. Otherwise, proceed to Write phase. –Write phase: The values stored in local variables overwrite the value of the data items in the database. A transaction has three time stamps: –Start(T i ): When T i started its execution. –Validation(T i ): When T i finished its read phase and started its validation –Finish(T i ): done with the write phase. TS(T i ) = Validation(T i ) instead of Start(T i ) because it produces a better response time if the conflict rate between transactions is low.

44. 2015-10-2544 OPTIMISTIC CC (VALIDATION TECHNIQUE) (Cont…) When validating transaction T j, for all transactions T i with TS(T i ) < TS(T j ), one of the following must hold: –Finish(T i ) < Start(T j ), OR –Set of data items written by T i does not intersect with the set of data items read by T j and T i completes its write phase before T j starts its validation phase. –Rational: Serializability is maintained because the write of T i cannot affect the read of T j and since T j cannot affect the read of T i because: Start(T j ) < Finish(T i ) < Validation(T j )