18.8 Concurrency Control by Timestamps CS257 Student Chak P. Li

Timestamping 1.Assign a timestamp to each transaction 2.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

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.

Physically Unrealizable Behaviors Read too late Transaction T tries to read too late

Physically Unrealizable Behaviors Write too late Transaction T tries to write too late

Problems with Dirty Data Dirty read T could perform a dirty read if it reads X when shown

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

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.

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.5Multiversion 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.5Multiversion Timestamps T3 must abort because it cannot access an old value of A

18.8.5Multiversion 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.6Timestamps 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.