The basic idea is to order the transaction based on their timestamps. This protocol ensures that any conflicting read and write operation are executed in time stamp order. This protocol works as follow:
Suppose that transaction Ti issues read (q)
If Ts(Ti) < W – time stamp (Q)
Then Ti needs to read a value of Q was already overwritten, hence the read operation is rejected and Ti rolled back. Here co-timestamp (Q) denotes the largest timestamp of any transaction that executed write (Q) successfully.
If Ts (Ti) > w – timestamp (2)
Then Ti needs to read the value of Q i.e. read operation is executed and (Q) is set to the maximum of R and Ts (Ti)
suppose that transaction Ti issues write Q of Ts(Ti) < R – timestamp (q) then the value of Q that Ti is producing was needed previously, and the spectrum assumed that the value will never be produced.
Hence, the system rejects the write operation and rolls Ti back. If Ts(Ti) < W – write stamp (Q) then Ti is attempting to write an absolute value of Q, hence, the system rejects this write operation and rolls Ti back.
Otherwise, the system executed the write operation and sits, w- timestamp (Q) to Ts (Ti)
Suppose there are 2 transactions T1 & T2, T2 displays the content 01 account A and B there as T2 transfer Rs 100 from account A to account B and display sum of both the two transactions T1 & T2 can be illustrated as follow:
Ti : read (A)
Display (A + B)
T2 : read (B)
B = B – 100
A = A + 100
Display (A + B)
Here, the assumption is that a transaction is assigned to a time stamp immediately before its first instruction. Thus a schedule Ts(t1) < TS(+2)
The time stamp adding protocol ensures conflicted serialization. This is because conflicting operations are processed in timestamp ordering. This protocol ensures freedom from dead lock since no transaction ever waits.