18.8 Concurrency Control by Timestamps

CS257 Student Chak P. Li

Timestamping

1. Assign a timestamp to each transaction2. Record the time stamps of the transactions

that last read and write each database element

3. Compare these values with the transactions timestamps to ensure the serial schedule is equivalent to the actual schedule

18.8.1 Timestamps• Scheduler assigns to each transaction T an unique number TS(T) using

1)the system clock or 2)a counter• RT(X) = the read time of database element X = the highest timestamp

of a transaction that has read X• WT(X) = the write time of database element X = the highest

timestamp of a transaction that has written X• C(X) = the commit bit for database element X = true if and only if the

most recent transaction to write X has already committed*.• *The purpose of this bit is to avoid a situation where one transaction T

reads data written by another transaction U and U then aborts. This problem where T makes a “dirty read” of uncommited data can cause the database state to become inconsistent and any scheduler needs a mechanism to prevent dirty reads.

18.8.2 Physically Unrealizable Behaviors

• Read too late

• Transaction T tries to read too late

18.8.2 Physically Unrealizable Behaviors

• Write too late

• Transaction T tries to write too late

18.8.3 Problems with Dirty Data

• Dirty read

• T could perform a dirty read if it reads X when shown

18.8.3 Problems with Dirty Data

• Thomas rule = writes can be skipped when a write with a later write time is already in place

• Write by T is skipped because write by U with a later timestamp, but writer by U then aborts

18.8.4 The rules for timestamp-based scheduling

• Suppose the scheduler receives a request rT(X). – (a) If TS(T) > WT(X), the read is physically

realizable.– (b) If TS(T) < WT( X ) , the read is physically

unrealizable (read too late). Abort T and restart it with a new, larger timestamp.

18.8.4 The rules for timestamp-based scheduling

• Suppose the scheduler receives a request wT(X).

• (a) If TS(T) > RT(X) and TS(T) > WT(X), the write is physically realizable and must be performed.

• (b) If TS(T) < RT(X), then the write is physically unrealizable (write too late). Abort T and restart it with a new, larger timestamp.

18.8.5 Multiversion Timestamps

• An important variation of timestamping maintains old versions of database elements in addition to the current version that is stored in the database itself.

• The purpose is to allow rT(X) that otherwise would cause transaction T to abort to proceed by reading the version of X that is appropriate for a transaction with T ’s timestamp.

18.8.5 Multiversion Timestamps

• T3 must abort because it cannot access an old value of A

18.8.5 Multiversion Timestamps

• Consider the set of transactions accessing database element A. These transactions are operating under an ordinary timestamp-based scheduler, and when T3 tries to read A, it finds WT(A) to be greater than its own timestamp (read too late), and must abort.

• However, there is an old value of A written by T1 and overwritten by T2 that would have been suitable for T3 to read; this version of A had a write time of 150, which is less than T3’s timestamp of 175. If this old value of A were available, T3 could be allowed to read it, even though it is not the “current” value of A.

18.8.6 Timestamps Versus Locking

• Generally, timestamping is superior in situations where either most transactions are read-only, or it is rare that concurrent transactions will try to read and write the same element. In high-conflict situations, locking performs better. The argument for this rule-of-thumb is:– Locking will frequently delay transactions as they wait for

locks.– But if concurrent transactions frequently read and write

elements in common, then rollbacks will be frequent in a timestamp scheduler, introducing even more delay than a locking system.