This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these template messages) This article does not cite any sources. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed.Find sources: "Timestamp-based concurrency control" – news · newspapers · books · scholar · JSTOR (June 2007) (Learn how and when to remove this template message) This article's factual accuracy is disputed. Relevant discussion may be found on the talk page. Please help to ensure that disputed statements are reliably sourced. (April 2012) (Learn how and when to remove this template message) This article provides insufficient context for those unfamiliar with the subject. Please help improve the article by providing more context for the reader. (March 2020) (Learn how and when to remove this template message) (Learn how and when to remove this template message)

In computer science, a timestamp-based concurrency control algorithm is a non-lock concurrency control method. It is used in some databases to safely handle transactions, using timestamps.

Operation

Assumptions

Generating a timestamp

A number of different ways have been used to generate timestamp

Formal

Each transaction () is an ordered list of actions (). Before the transaction performs its first action (), it is marked with the current timestamp, or any other strictly totally ordered sequence: . Every transaction is also given an initially empty set of transactions upon which it depends, , and an initially empty set of old objects which it updated, .

Each object in the database is given two timestamp fields which are not used other than for concurrency control: is the time at which the value of object was last used by a transaction, is the time at which the value of the object was last updated by a transaction.

For all :

For each action :
If wishes to use the value of :
If then abort (a more recent thread has overwritten the value),
Otherwise update the set of dependencies and set ;
If wishes to update the value of :
If then abort (a more recent thread is already relying on the old value),
If then skip (the Thomas Write Rule),
Otherwise store the previous values, , set , and update the value of .
While there is a transaction in that has not ended: wait
If there is a transaction in that aborted then abort
Otherwise: commit.

To abort:

For each in
If equals then restore and

Informal

Whenever a transaction begins, it receives a timestamp. This timestamp indicates the order in which the transaction must occur, relative to the other transactions. So, given two transactions that affect the same object, the operation of the transaction with the earlier timestamp must execute before the operation of the transaction with the later timestamp. However, if the operation of the wrong transaction is actually presented first, then it is aborted and the transaction must be restarted.

Every object in the database has a read timestamp, which is updated whenever the object's data is read, and a write timestamp, which is updated whenever the object's data is changed.

If a transaction wants to read an object,

If a transaction wants to write to an object,

Recoverability

For an explanation of the terms recoverable (RC), avoids cascading aborts (ACA) and strict (ST), see Schedule (computer science).

Note that timestamp ordering in its basic form does not produce recoverable histories. Consider for example the following history with transactions and :

This could be produced by a TO scheduler, but is not recoverable, as commits even though having read from an uncommitted transaction. To make sure that it produces recoverable histories, a scheduler can keep a list of other transactions each transaction has read from, and not let a transaction commit before this list consisted of only committed transactions. 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.

Implementation issues

Timestamp resolution

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. For example, assuming that we have a system that can create one hundred unique timestamps per second, and given two events that occur 2 milliseconds apart, they will probably be given the same timestamp even though they actually occurred at different times.

Timestamp locking

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.

See also