It is used in some databases to safely handle transactions using timestamps.
A number of different approaches can generate timestamps Each transaction (
), it is marked with the current timestamp, or any other strictly totally ordered sequence:
, and an initially empty set of old objects which it updated,
in the database is given two timestamp fields which are not used other than for concurrency control: For all
: To abort: Whenever a transaction initiated, it receives a timestamp.
The following are the only two situations that result in physically unrealizable behavior: Note that timestamp ordering in its basic form does not produce recoverable histories.
To avoid cascading aborts, the scheduler could tag data written by uncommitted transactions as dirty, and never let a read operation commence on such a data item before it was untagged.
To get a strict history, the scheduler should not allow any operations on dirty items.
This is the minimum time elapsed between two adjacent timestamps.
If the resolution of the timestamp is too large (coarse), the possibility of two or more timestamps being equal is increased and thus enabling some transactions to commit out of correct order.
Even though this technique is a non-locking one, in as much as the object is not locked from concurrent access for the duration of a transaction, the act of recording each timestamp against the Object requires an extremely short duration lock on the Object or its proxy.