Prepared By: Ronak Shah
Professor :Dr. T. Y Lin
Concurrency is a property of a systems in which
several computations are executing and overlapping
in time, and interacting with each other.
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
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.
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
Rules for timestamp based scheduling
Scheduler’s Response to a T’s request for Read(X)/Write(X)
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
1. If TS(T) >= WT(X), the read is physically
I. If C(X) is true, grant the request. If TS(T) >
RT(X), set RT(X) := TS(T); otherwise do not
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
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
Timestamps Vs Locks
Superior if Superior in high-conflict situations
• most transactions are read-only
• rare that concurrent transactions
will read or write the same element
In high-conflict situations, rollback will Frequently delay transactions as they
be frequent, introducing more delays wait for locks
than a locking system