[grogers]

When executing a transaction with a given timestamp on some node, doesn't the node have to guarantee that it will no longer accept commits with a smaller timestamp? Without that commitment, you could read a piece of data that is later updated by a transaction that occurred logically before you, breaking serializablility and/or snapshot isolation.

The spanner paper is unclear how they deal with this, but my guess is that since they have accurately synchronized clocks, you'll never have to block long for that commitment to hold. Spanner also uses pessimistic locking, so for a R/W transaction, you can rely on locking reads to prevent the anomaly.

With cockroachdb, wouldn't this commitment imply that poorly synchronized clocks would lead to poor performance?

[hnkimb3558]

Cockroach enforces this guarantee on a per-key basis as opposed to for the entire node. If a key has been read at time t, it may only be subsequently written at time > t. CockroachDB accomplishes this using a timestamp cache at the leader node for a range. But this doesn't cause writes to block. Instead, the write timestamp is pushed to the most recent read + 1 logical tick.

[grogers]

Interesting, thanks for the info.

Do reads execute through raft? If not, how do you guarantee that behavior - relying on leader leases? If so, does the lease period guarantee disjointness in the timestamps a leader can process, or do you rely on the leader abdicating control via timeout?

Since it can push the write timestamp, does that mean the write transaction aborts if it was in serializable mode? Does that cause problems updating a value that is heavily read?