Concurrency III Timestamps

1
Concurrency III (Timestamps)
2
Schedulers

• A scheduler takes requests from transactions for
  reads and writes, and decides if it is OK to
  allow them to operate on DB or defer them until
  it is safe to do so.
• Ideal a scheduler forwards a request iff it
  cannot lead to inconsistency of DB

3
Timestamps

• Unique value representing a time.
• Example clock time.
• Example serial counter.

4
Serializability Via Timestamps

• Main idea let things rumble along without any
  locking or scheduling (be optimistic)
• As transactions read/write, check that what they
  are doing makes sense if the serial order was the
  same as the order in which transactions
  initiated.
• Big gain if most transactions are readonly.
• Every transaction T is given a timestamp TS(T)
  when it is initiated.

5
Serializability Via Timestamps (Continued)

• Every DB element X has two timestamps
• 1. RT (X) highest timestamp of a transaction to
  read X.
• 2. WT (X) highest timestamp of a transaction to
  write X.
• Every DB element X has a bit C(X) indicating
  whether the most recent writer of X has
  committed.
• Essential to avoid a dirty read, where a
  transaction reads data that was written by a
  transaction that later aborts.

6
Physically Unrealizable Behaviors

• The scheduler assumes the timestamp order of
  transactions is also the serial order in which
  they must appear to execute.
• Scheduler needs to check that
• whenever a read or write occurs, what happens
  in real time could have happened if each
  transaction had executed instantaneously at the
  moment of its timestamp.
• If not, we say the behavior is physically
  unrealizable.

7
What is Physically Unrealizable?

• Read Too Late Transaction T tries to read X, but
  TS(T) lt WT(X).
• T would read something that was written after T
  apparently finished.

8
But Wait if Data is Dirty?

• T tries to read X, and TS(T)gtWT(X), but C(X)
  false.
• T would be reading dirty data --- a risk we won't
  take.

9
What is Physically Unrealizable?

• Write Too Late Transaction T tries to write X,
  but
• TS(T)ltRT(X)
• Some other transaction read a value written
  earlier than T write, when it should have read
  what was written by T.

10
What is Physically Unrealizable?

• Write Too Late Transaction T tries to write X,
  but RT(X)gtTS(T)gtWT(X).
• When T tries to write X it finds RT(X)gtTS(T).
  This means that X has already been read by some
  transaction that theoretically executed after T.
• We also find TS(T)gtWT(X), which means that no
  other transaction wrote into X a value that would
  have overwritten Ts value, negating T
  responsibility for the value of X.
• This idea that writes can be skipped when a write
  with a later write-time is already in place, is
  called Thomas rule.

11
Thomas Write Rule

• If U later aborts, then its value of X should be
  removed and the previous value and write-time
  restored.
• Since T is committed, it would seem that the
  value of X should be the one written by T for
  future reading.
• However, we already skipped the write by T and it
  is too late to repair the damage.

12
Abort/Update Decision

• Legal Physically Realizable.
• Illegal Physically Unrealizable.
• If illegal, rollback T abort T and restart it
  with a new timestamp.
• When a transaction finishes with no rollback,
  commit the transaction by changing all C(X) bits
  to true.

13
Rules, in detail

• Suppose the scheduler receives a request rT(X),
• (a) If TS(T) ? WT(X), the read is physically
  realizable.
• i. If C(X)true, grant the request.
• If TS(T) gt RT(X), set RT(X) TS(T)
• otherwise do not change RT(X).
• ii. If C(X)false, delay T until C(X) becomes
  true, or the transaction that wrote X aborts.
• (b) If TS(T) lt WT(X), the read is physically
  unrealizable.
• Rollback T that is, abort T and restart it with
  a new, larger timestamp.

14
Rules, in detail

• Suppose the scheduler receives a request wT(X),
• (a) If TS(T) ? RT(X) the write is physically
  realizable
• If TS(T) ? WT(X), the write must be performed.
• i. Write the new value for X,
• ii. Set WT(X) TS(T), and
• iii. Set C(X) false.
• If TS(T) lt WT(X), then there is already a later
  value in X.
• If C(X)true, then the previous writer of X is
  committed, and we simply ignore the write by T
• Otherwise, if C(X)false, then we must delay T.
• (b) If TS(T) lt RT(X), then the write is
  physically unrealizable, and T must be rolled
  back.

15
Rules, in detail

• Suppose the scheduler receives a request to
  commit T.
• It must find all the database elements X written
  by T, and set c(X) true.
• If any transactions are waiting for X to be
  committed, these transactions are allowed to
  proceed.
• Suppose the scheduler receives a request to abort
  T or decides to rollback T.
• Then any transaction that was waiting on an
  element X that T wrote must repeat its attempt to
  read or write, and see whether the action is now
  legal after T's writes are cancelled.

16

• T2 aborts because it tries to write at time 150
  when another value of C was already read at time
  175.
• T3 is allowed to write A, but since there is
  already a later write of A, the DB is not
  affected.

17
Timestamps Versus Locks

• Locking requires a lock table for currently
  locked items, while timestamping uses space for
  two timestamps in each DB element, locked or not.
  
• Locking may cause transactions to wait
  timestamping doesn't cause waiting, but may abort
  transactions.
• Net effect if most transactions are read only
  or few transactions interfere, then timestamping
  gives better throughput otherwise not.