Timestamp-Based Concurrency Control

  1. Timestamp-Based Concurrency Control (Update the timestamp rules by using the algorithm on pages 565-567). We have assumed that the only way to assure serializable behavior of transactions was to maintain and enforce locks on items. There are other ways one could enforce serializability as well. As an extreme example, the scheduler could construct the conflict graph based on all reads and writes it has issued to active transactions, and only allow an additional access to take place if it does not cause a cycle in that graph. While such a scheme is possible, it is hardly practical. However, another approach has been used in practice, and it is appropriate in situations where aggressive locking makes sense, that is, when it is unlikely that two transactions executing at about the same time will need to access the same item. The general idea is to give each transaction a "timestamp" which indicates when the transaction began (serial number or system time). The rule for preserving serial order using timestamps is the following. Suppose we have a transaction with timestamp t that attempts to perform an operation X on an item with read-time tr and write-time tw. 1. Perform the operation if X = READ and t >= tw or if X = WRITE, t >= tr, and t >= tw. In the former case, set the read-time to t if t > tr, and in the latter case, set the write-time to t if t > tw. 2. Do nothing if X = WRITE and tr <= t less than tw 3. Abort the transaction if X = READ and t less than tw or X =WRITE and t less than tr Example1 (A schedule without any concurrency control). It results in a problem of lost update. T1 T2 READ A READ A A =A +1 A=A+1 WRITE A WRITE A Example2 (Using Timestamps), T1 T2 A 150 160 RT=0 WT=0 READ A RT=150 READ A RT=160 A=A+1 A=A+1 WRITE A WT=160 WRITE A T1 aborts Example3, T1 T2 T3 A B C 200 150 175 RT=0 RT=0 RT=0 WT=0 WT=0 WT=0 R B RT=200 R A RT=150 R C RT=175 W B WT=200 W A WT=200 W C T2 aborts W A T2 cannot perform the write and must be aborted. T3 tries to write A. As T3 has a timestamp, 175, that is bigger than the read-time of A, which is 150, T3 need not abort. However, the write-time of A is 200, so the value of A written by T3 is not entered into the database, but rather is discarded. Excercise: T1 T2 T3 T4 READ A READ A WRITE B WRITE A READ B READ B READ A WRITE C WRITE A Which, if any of the four transactions abort on the assumption that the timestamps of T1 through T4 respectively. a) 300, 310, 320, and 330 b) 250, 200, 210, and 275

Last update March 2, 1998.