Concurrency Control By Timestamps

Document Sample
Concurrency Control By Timestamps Powered By Docstoc
					Prepared By: Ronak Shah
   Professor :Dr. T. Y Lin
                   ID: 116
 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 PM
06/20/2003 16:55:14:000000
 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
then aborts
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
Request RT(X):
  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
          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
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
Timestamps Vs Locks

             Timestamps                                    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

Shared By: