Timestamp Ordering Protocol

The Timestamp Ordering Protocol is used to order the transactions based on their Timestamps. The order of transaction is nothing but the ascending order of the transaction creation.
The priority of the older transaction is higher that's why it executes first. To determine the timestamp of the transaction, this protocol uses system time or logical counter.
The lock-based protocol is used to manage the order between conflicting pairs among transactions at the execution time. But Timestamp based protocols start working as soon as a transaction is created.
Let's assume there are two transactions T1 and T2. Suppose the transaction T1 has entered the system at 007 times and transaction T2 has entered the system at 009 times. T1 has the higher priority, so it executes first as it is entered the system first.
The timestamp ordering protocol also maintains the timestamp of last 'read' and 'write' operation on a data.

Basic Timestamp ordering protocol works as follows:

The basic timestamp ordering methods make sure that any conflicting read and write operations are executed.

1. Check the following condition whenever a transaction Ti issues a Read (X) operation:

If W_TS(X) >TS(Ti) then the operation is rejected.
If W_TS(X) <= TS(Ti) then the operation is executed.
Timestamps of all the data items are updated.

2. Check the following condition whenever a transaction Ti issues a Write(X) operation:

If TS(Ti) < R_TS(X) then the operation is rejected.
If TS(Ti) < W_TS(X) then the operation is rejected and Ti is rolled back otherwise the operation is executed.

Where,

TS(TI) denotes the timestamp of the transaction Ti.

R_TS(X) denotes the Read time-stamp of data-item X.

W_TS(X) denotes the Write time-stamp of data-item X.

Advantages and Disadvantages of TO protocol:

TO protocol ensures serializability since the precedence graph is as follows:
TS protocol ensures freedom from deadlock that means no transaction ever waits.
But the schedule may not be recoverable and may not even be cascade- free.

To illustrate this mechanism, we shall consider two transactions T1 and T2. Both the transaction subtracts a 200 from A and adds it to B. The timestamps of T1 and T2 are 5:29 pm and 5:30 pm respectively. Initially all the system clock is set to zero.

Once restarted the transaction T1 will acquire new timestamp (say 5:31 pm).

Schedule	Read_TS(A)	Write_TS(A)	Read_TS(B)	Write_TS(B)	Description
T1: Read (A)	5 : 29	0	0	0	After T1 reads the Read_TS (A) becomes 5 : 29 and remains so till T1 reads B.
T1: A: = A -200	5 : 29	0	0	0
T1: Read (B)	5 : 29	0	5 : 29	0	Now both Read_TS (A), Read_TS(B) becomes 5 : 29
T2: Read (A)	5 : 30	0	5 : 29	0	Using rule 1(b) since 5: 30 > 5:29 so Read_TS(A) is updated.
T2: Read (B)	5 : 30	0	5 : 30	0	Using rule 1(b) since 5: 30 > 5:29 so Read_TS(B) is updated.
T2: A: = A -200	-	-	-
T2: B: = B + 200	-	-	-		No read or write operation.
T2: Write (A)	5 : 30	5 : 30	5 : 30	0	Using rule 2(c), Write_TS (A) updated.
T2: Write (B)	5 : 30	5 : 30	5 : 30	5 : 30	Using rule 2(c), Write_TS (B) updated.
T1: B: = B + 200	-	-		No read or write operation.
T1: Write (A)	5 : 30	conflict	5 : 30	5 : 30	Using rule 2(b), since 5: 30 > 5:29 so transaction T1 is aborted.
T1: Write (B)

It can be verified that schedule produces the correct result even if T1 has aborted but this is not always the case. This method guarantees that the transactions are conflict serializable and the results are equivalent to a serial schedule in which transaction are executed in the timestamp order. The basic timestamp ordering method would be the same as if all transactions were executed one after the other without any interference.

Next TopicDBMS Validation based Protocol

← prev next →