1. Prepared By: Ronak Shah Professor :Dr. T. Y Lin ID: 116

2. Concurrency Concurrency is a property of a systems in which several computations are executing and overlapping in time, and interacting with each other. Timestamp Timestamp is a sequence of characters, denoting the date or time at which a certain event occurred. Example of Timestamp: 20-MAR-09 04.55.14.000000 PM 06/20/2003 16:55:14:000000

3. Timestamping We assign a timestamp to transaction and timestamp is usually presented in a consistent format, allowing for easy comparison of two different records and tracking progress over time; the practice of recording timestamps in a consistent manner along with the actual data is called timestamping.

4. Timestamps To use timestamping as a concurrency-control method, the scheduler needs to assign to each transaction T a unique number, its timestamp TS(T). Here two approaches use to generating timestamps 1. Using system clock 2. Another approach is for the scheduler to maintain a counter. Each time when transaction starts the counter is incremented by 1 and new value become timestamp for transaction.

5. Whichever method we use to generate timestamp, the scheduler must maintain a table of currently active transaction and their timestamp.  To use timestamps as a concurrency-control method we need to associate with each database element x two timestamps and an additional bit. RT(x) The read time of x. WT(x) The write time of x. C(x) The commit bit of x. which is 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 of “Dirty Read”.

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

7. Write too late Transaction T tries to write too late

8. Problem with dirty data T could perform a dirty read if it is reads X

9. A write is cancelled because of a write with a later timestamp, but the writer then aborts

10. Rules for timestamp based scheduling 1. Granting Request 2. Aborting T (if T would violate physical reality) and restarting T with a new timestamp (Rollback) 3. Delaying T and later deciding whether to abort T or to grant the request Scheduler’s Response to a T’s request for Read(X)/Write(X)

11. Request RT(X): 1.If TS(T) >= WT(X), the read is physically realizable I.If C(X) is true, grant the request. If TS(T) > RT(X), set RT(X) := TS(T); otherwise do not change RT(X) II.If C(X) is false, delay T until C(X) becomes true or the transaction that wrote X aborts 2.If TS(T) < WT(X), the read is physically unrealizable. Rollback T; abort T and restart it with a new, larger timestamp Rules

12. Request WT(X): 1.If TS(T) >= RT(X) and TS(T) >= WT(X), the 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 2.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. If C(X) is true, then ignore the write by T. If C(X) is false, delay T 3.If TS(T) < RT(X), then the write is physically unrealizable

13. Timestamps Vs Locks TimestampsLocks Superior if most transactions are read-only rare that concurrent transactions will read or write the same element Superior in high-conflict situations In high-conflict situations, rollback will be frequent, introducing more delays than a locking system Frequently delay transactions as they wait for locks