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

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 PM 06/20/ :55:14:000000

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.

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.

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”.

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

Write too late Transaction T tries to write too late

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

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

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)

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

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

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