The Gold Standard
Serializable isolation guarantees that concurrent transactions produce a result equal to some serial order, eliminating anomalies like write skew. Across shards this is hard because there is no single lock manager.
Two Common Approaches
- Strict two phase locking with distributed locks: transactions hold locks across shards until commit, ordering conflicts directly but risking deadlock and blocking.
- Serializable snapshot isolation plus timestamp ordering: transactions read a consistent snapshot and the system aborts those whose commit would violate serial order.
Distributed SQL engines often combine MVCC snapshots with read refreshes and conflict checks so most transactions commit without blocking.
Detecting Conflicts
Each transaction gets a commit timestamp. Before committing, the engine verifies that nothing it read was overwritten by an earlier committing transaction in a way that would break the serial order. If so, the transaction restarts. Write skew, where two transactions each read what the other writes, is caught here because their read sets and write sets overlap in a conflicting way.
Key idea
Distributed serializability combines MVCC snapshots with timestamp ordering and conflict checks, restarting transactions that would break the serial order rather than relying on one global lock.