Concurrency Control by Timestamps

1. Concurrency Control by Timestamps AnanthGopal CS257 008020077

2. Index • 18.8.1 Timestamps • 18.8.2 Physically Unrealizable Behaviors • 18.8.3 Problems With Dirty Data • 18.8.4 The Rules for Timestamp-Based Scheduling • 18.8.5 Multiversion Timestamps • 18.8.6 Timestamps Versus Locking

3. Timestamp TS(T) • Scheduler assign each transaction T a unique number, it’s timestamp TS(T). • The timestamp ordering protocol ensures that any conflicting read and write operations are executed in timestamp order.

4. Timestamp… • Each transaction is issued a timestamp when it enters the system. • If an old transaction T1 has timestamp TS(T1), a new transaction T2 is assigned time-stamp TS(T2) such that TS(T1) <TS(T2)

5. Approaches for generating Timestamp • Use the value of system, clock as the timestamp; that is, a transaction’s timestamp is equal to the value of the clock when the transaction enters the system • Use a logical counter that is incremented after a new timestamp has been assigned; that is, a transaction’s is equal to the value of the counter when the transaction enters the system.

6. Timestamp based protocol implementation • RT(X) Highest timestamp of a transaction that has read X. • WT(X) Highest timestamp of a transaction that has written X. • C(X) Commit bit for X, which is true if and only if most recent transaction to write X has already committed. Associate each database element X with two timestamp values and an additional bit

7. Timestamp based protocol implementation • Purpose of this bit is to avoid a situation where one transactions T reads data written by another transaction U, and U then aborts. => ”dirty read” • These time stamps are updated whenever a new Read(X) or Write(X) instruction is executed.

8. U writes X T reads X T start U start Physically Unrealizable Behaviors • Read very late A transaction U that started after transaction T, but wrote a value for X before T reads X. Figure: Transaction T tries to read too later

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

10. U writes X T reads X U start T start U aborts T could perform a dirty read if it reads X when shown Problems with Dirty Data • Dirty Read: It is possible that after T reads the value of X written by U, transaction U will abort.

11. U writes X T writes X T start U start T commits U aborts Figure: A write is cancelled because of a write with a later timestamp, but the writer then aborts Problems with Dirty Data • Thomas Write Rule Write can be skipped when a write with a later write-time is already in place.

12. Problems with Dirty Data • A simple policy When a transaction T writes a database element X, the write is “tentative” and maybe undone if T aborts. The commit bit C(X) is set to false, and the scheduler makes a copy of the old value of X and its previous WT(X).

13. The Rules of Timestamp-Based Scheduling Four Classes • the scheduler receives a request RT(X) • the scheduler receives a request WT(X) • the scheduler receives a request to commit T • the scheduler receives a request to abort T or decides to rollback T

14. The Rules of Timestamp-Based Scheduling(1) • Scheduler receives a request RT(X) (a) If TS(T)>=WT(X), the read is physically realizable. i. If C(X) is true, grant the request. ii. If C(X) is false, delay T until C(X) becomes true or the transaction that wrote X aborts. (b) If TS(T)<WT(X), the read is physically unrealizable, abort T and restart it with a new, larger timestamp.

15. The Rules of Timestamp-Based Scheduling(2) • 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. i. Write the new value for X ii.Set WT(X):=TS(T), and iii. Set C(X):= false.

16. The Rules of Timestamp-Based Scheduling(2) • (b) If TS(T)>=RT(X), but TS(T)<WT(X), then the write is physically realizable, but there is already a later value in X. i. If C(X) is true, then the previous writers of X is committed, and ignore the write by T. ii. If C(X) is false, we must delay T. (c) If TS(T)<=RT(X), the write is physically unrealizable, and T must be rolled back.

17. The Rules of Timestamp-Based Scheduling(3&4) • The scheduler receives a request to commit T. It must find all the database elements X written by T, and set C(X):= true. • The scheduler receives a request to abort T or decides to rollback T. Any transaction that was waiting on an element X that T wrote must repeat its attempt to read or write, and see whether the action is now legal after the aborted transaction’s writes are cancelled.

18. MultiversionTimestamps • Multiversion schemes keep old versions of data item to increase concurrency. • Multiversion Timestamp Ordering • Multiversion Two-Phase Locking • 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. • reads never have to wait as an appropriate version is returned immediately.

19. Timestamps and Locking • Generally, using Timestamp is superior to locking in these situations - 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