Timestamp Concurrency Control: No Locks, Just Time

WHY IT EXISTS To handle concurrent database transactions safely without the performance bottlenecks and deadlock risks of traditional locking. It was designed for high-throughput systems where conflicts are expected to be infrequent, and the overhead of managing locks is too costly.

THE MENTAL MODEL Think of it as a "commit first, ask for forgiveness later" strategy. Instead of locking data upfront to prevent others from touching it (pessimistic), it lets all transactions proceed as if they won't conflict. Each transaction gets a timestamp, like a ticket number. At the end, the system checks if its work violates the timestamp order. If a conflict is found, the transaction is aborted and must try again.

HOW IT WORKS This algorithm uses timestamps for synchronization instead of locks. When a transaction starts, it is assigned a unique, monotonic timestamp. The system uses these timestamps to enforce a serializable execution order. If a transaction attempts an operation that conflicts with an already committed operation from a transaction with a later timestamp, it violates the order. The system detects this conflict and aborts the offending transaction, preserving database consistency. The transaction must then be restarted with a new timestamp.

WHEN TO USE IT Use this in systems where transaction conflicts are genuinely rare, such as those with high read-to-write ratios or workloads where users are not modifying the same data. It excels where the cost of acquiring and releasing locks creates a performance bottleneck and the application can tolerate occasional transaction rollbacks.

WHEN NOT TO USE IT Avoid this in high-contention environments where many transactions are likely to modify the same data. The optimistic assumption breaks down here, leading to a high rate of transaction aborts and retries. This "livelock" can degrade performance more severely than a pessimistic locking strategy would have.

ONE CANONICAL EXAMPLE The source does not provide a specific example of a database that uses this method. However, it is an optimistic concurrency control method used in some database systems as an alternative to lock-based approaches, especially in distributed systems where managing locks across a network is complex and slow.