SECTION 18.8 Timestamps

What is Timestamping? Scheduler assign each transaction T a unique number, it’s timestamp TS(T). Timestamps must be issued in ascending order, at the time when a transaction first notifies the scheduler that it is beginning.

Timestamp TS(T) Two methods of generating Timestamps. Use the value of system, clock as the timestamp. Use a logical counter that is incremented after a new timestamp has been assigned. Scheduler maintains a table of currently active transactions and their timestamps irrespective of the method used

Timestamps for database element X and commit bit RT(X):- The read time of X, which is the highest timestamp of transaction that has read X. WT(X):- The write time of X, which is the highest timestamp of transaction that has write X. C(X):- The commit bit for X, which is true if and only if the most recent transaction to write X has already committed.

Physically Unrealizable Behavior Read too late: A transaction U that started after transaction T, but wrote a value for X before T reads X. U writes X T reads X T startU start

Physically Unrealizable Behavior Write too late A transaction U that started after T, but read X before T got a chance to write X. U reads X T writes X T startU start Figure: Transaction T tries to write too late

Dirty Read It is possible that after T reads the value of X written by U, transaction U will abort. U writes X T reads X U startT startU aborts T could perform a dirty read if it reads X when shown

Rules for Timestamps-Based scheduling 1. Scheduler receives a request rT(X) a) If TS(T) ≥ WT(X), the read is physically realizable. 1. If C(X) is true, grant the request, if TS(T) > RT(X), set RT(X) := TS(T); otherwise do not change RT(X). 2. If C(X) is false, delay T until C(X) becomes true or transaction that wrote X aborts. b) If TS(T) < WT(X), the read is physically unrealizable. Rollback T.

Rules for Timestamps-Based scheduling (Cont.) 2. Scheduler receives a request WT(X). a) if TS(T) ≥ RT(X) and TS(T) ≥ WT(X), write is physically realizable and must be performed. 1. Write the new value for X, 2. Set WT(X) := TS(T), and 3. Set C(X) := false. b) if TS(T) ≥ RT(X) but TS(T) < WT(X), then the write is physically realizable, but there is already a later values in X. a. If C(X) is true, then the previous writers of X is committed, and ignore the write by T. b. If C(X) is false, we must delay T. c) if TS(T) < RT(X), then the write is physically unrealizable, and T must be rolled back.

Rules for Timestamps-Based scheduling (Cont.) 3. Scheduler receives a request to commit T. It must find all the database elements X written by T and set C(X) := true. If any transactions are waiting for X to be committed, these transactions are allowed to proceed. 4. Scheduler receives a request to abort T or decides to rollback T, then any transaction that was waiting on an element X that T wrote must repeat its attempt to read or write.

Multiversion Timestamps Multiversion schemes keep old versions of data item to increase concurrency. Each successful write results in the creation of a new version of the data item written. Use timestamps to label versions. When a read(X) operation is issued, select an appropriate version of X based on the timestamp of the transaction, and return the value of the selected version.

Timestamps and Locking Generally, timestamping performs better than locking in situations where: Most transactions are read-only. It is rare that concurrent transaction will try to read and write the same element. In high-conflict situation, locking performs better than timestamps