Timestamp ordering and validation

A timestamp can be a monotonically allocated logical label rather than a reading from a wall clock. A concurrency-control protocol may use it to select versions or enforce a serialization order. State when the label is assigned and what comparisons mean. Physical time introduces uncertainty and synchronization assumptions, especially across machines. Unrelated local counters cannot automatically be compared as one global order, while a total order alone does not prove that the transaction read versions consistent with that order.

Basic timestamp-ordering schemes maintain metadata such as the largest read and write timestamps associated with an item, rejecting operations that would violate the chosen order. Optimistic schemes instead often read first and validate later. These are related approaches with different rules, not interchangeable descriptions of one algorithm. A production design must specify handling of predicates, insertions, deletes, and blind writes as well as single-record updates. A transaction can violate an invariant through a changed query result even when none of the rows it happened to return was overwritten.

If two validators both inspect old state and then publish incompatible writes without coordination, each local check can pass while their combined execution is wrong. A correct protocol integrates validation with an ordering, locking, or certification mechanism that protects the intended serialization point. In a distributed transaction, that protection must cover the relevant participants. Collecting independently valid statements from different instants does not create one atomic global validation snapshot. Atomic commit still has to coordinate their final outcome.

Keep candidate writes private until the protocol authorizes publication, and preserve enough read or predicate metadata to validate the transaction’s actual decisions. On validation failure, restart the logical computation with new reads instead of repeatedly submitting the same stale write set. A useful conflict report identifies the record or predicate involved, observed and conflicting versions, and the validation phase. That evidence helps distinguish contention from a broken versioning implementation or an application that performed essential reads outside the transaction.

Spanner combines clock uncertainty bounds with concurrency control, replication, and distributed commit. Its external-consistency argument is not merely that timestamps look like real time. When discussing such a system, identify how uncertainty is bounded, how a timestamp is selected, and when waiting establishes the required ordering relative to real-time completion. Do not transplant a commit-wait expression into a database that lacks the surrounding guarantees. Clock accuracy can affect waiting, but an accurate clock cannot repair a missing validation or atomic-commit step.

The queue lab illustrates validator capacity rather than certification correctness. Reset, set arrival rate to 4 and service rate to 3, predict backlog after one second, then Step twice. Start a separate run with Reset and both rates explicitly set to 2 and 3; predict before two Steps. Each starts with four units. The difference exposes queued validation work only. It does not model timestamp assignment, conflict graphs, clock uncertainty, or transaction decisions, so verify those properties with an explicit execution trace.