Recommended Free Tools
Google Cloud Spanner uses TrueTime’s bounded clock uncertainty together with commit wait to assign transaction timestamps that preserve real-time order. TrueTime is not a perfectly synchronized global clock: it gives Spanner a time interval, allowing the database to determine when a chosen commit timestamp is definitely in the past. Spanner then combines those timestamps with multi-version concurrency control (MVCC) so transactions can be ordered consistently while reads use coherent snapshots.
What TrueTime tells Spanner
TrueTime is a distributed clock API available on Google servers. Rather than claiming one exact time everywhere, it returns bounds around the current time. Spanner can use those bounds to determine whether a timestamp is certainly earlier or later than real time. Google describes it as “a highly available, distributed clock that is provided to applications on all Google servers” in its TrueTime and external consistency documentation.
That bounded knowledge matters because a distributed database cannot safely infer transaction order from a clock reading that might be ahead or behind elsewhere. Spanner assigns each committed transaction a timestamp that places it in the database’s serial history, while respecting real-time order where the client-visible sequence requires it.
How timestamp assignment and commit wait work together
- Prepare the transaction. Spanner processes the transaction and determines the data changes to commit.
- Choose a commit timestamp. The timestamp gives the transaction a position in the serial history. Timestamp assignment by itself does not prove that this position is already in the past.
- Wait for certainty. The leader waits until TrueTime’s earliest possible current time has advanced beyond the chosen commit timestamp. At that point, the timestamp is certainly earlier than the current time.
- Acknowledge the commit. Only after the wait can Spanner report the write transaction as successfully committed. This prevents a transaction that follows an already completed transaction from being externally placed earlier in history.
Google’s Life of Spanner Reads & Writes whitepaper describes commit wait as typically requiring a few milliseconds and overlapping with replica communication. That is a qualitative description, not a universal latency figure or service-level guarantee.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstall#1 Best Overall
What external consistency guarantees
External consistency means the committed history behaves like a serial execution and preserves transaction order that clients could observe in real time. If transaction A has finished before transaction B begins committing, Spanner’s timestamps will not put B before A. A reader therefore cannot observe B’s effects as though they came first while omitting A’s earlier committed effects.
This is stronger than serializability alone. Serializability requires an equivalent serial order, but that order need not match the order clients observed in real time. Google’s documentation describes Spanner’s external consistency guarantee as stronger than linearizability as used for single-object operations: it applies to transactions that can involve multiple operations. It does not impose a deterministic order on transactions that overlap in time; the guarantee constrains the order when the relevant real-time relationship exists. See Spanner transaction guarantees for the transaction-level description.
Rank #2
How MVCC makes timestamped reads possible
Spanner uses multi-version concurrency control (MVCC): it retains immutable versions of data associated with timestamps. A read at a chosen timestamp can therefore return a consistent snapshot of the database at that point in the transaction history without requiring every read to stop writes. The timestamp links the read to a coherent version of the data; the selected read mode determines how recent that point must be and whether it is fixed or chosen by Spanner.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Which read mode should an application use?
Choose based on how fresh the data must be, whether the read can use a replica without waiting for the latest version, and whether separate calls must share one snapshot. Google’s timestamp bounds documentation describes the read options and their semantics.
Rank #3
| Read choice | Timestamp behavior | Useful when | Repeatability across calls |
|---|---|---|---|
| Strong read (default) | Reflects transactions committed before the read starts. | Freshness and straightforward application reasoning matter most. | Separate strong reads can see changes committed between calls. |
| Bounded staleness | Spanner chooses a recent timestamp within the staleness bound supplied by the application. | The application can accept older data and may benefit from reading closer to a replica without waiting for the very latest version. | Two reads with the same bound need not use the same timestamp. |
| Exact staleness | The application specifies a timestamp or age for the read. | A fixed point in the transaction history is needed, including for repeated reads using that same exact timestamp. | Reusing the same exact timestamp can provide a consistent view; the read can wait for conflicting transactions that might have timestamps at or below that point. |
Bounded and exact staleness do not mean eventual consistency: each read is a consistent snapshot from an earlier point in the transaction history. If several reads must share one view, use the same read-only transaction or reuse the same exact read timestamp. Use separate strong reads when each call should be fresh relative to its own start rather than pinned to an earlier shared snapshot.
Quick Recap
Rank #4
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
