Timestamp-based concurrency control
Timestamp-based concurrency control (TBCC) is a non-locking method used by some databases to coordinate concurrent transactions. Each transaction starts with a unique timestamp that marks when it began. Every database object keeps two timestamps: a read timestamp (the latest time the object was read) and a write timestamp (the latest time the object was written).
The core rule is simple: operations from different transactions on the same object must follow the order of their timestamps. If a newer transaction’s operation would have to happen before an older one, the newer operation is aborted and the transaction restarts.
To make histories recoverable, the system can track which transactions a given transaction has read from, and a transaction should not commit until all the transactions it read from have committed. To avoid cascading aborts, data written by uncommitted transactions can be marked dirty, and reads of dirty data are prevented until the writer commits and clears the dirty tag. A strict history means no operations on dirty items.
A practical challenge is timestamp resolution. If the clock granularity is coarse (for example, 100 timestamps per second), two events occurring milliseconds apart might receive the same timestamp, potentially breaking the intended order. Although TBCC is often described as non-locking, recording a timestamp for each object typically requires a very short lock on that object or its proxy.
In short, TBCC enforces a global, time-based order on accesses to each object, aborting transactions when their operations would violate that order, and using dependency tracking and dirty data to improve safety and predictability.
This page was last edited on 2 February 2026, at 14:50 (CET).