Prepared By: Ronak ShahProfessor :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.

TimestampTimestamp 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

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

TimestampsTo 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 clock2.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 BehaviorsRead 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 Request2. 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

realizableI. 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 performed1. Write the new value for X2. Set WT(X) := TS(T), and3. 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

Timestamps Locks

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