Snapshot Isolation

Snapshot Isolation

In a snapshot isolated system, each transaction appears to operate on an independent, consistent snapshot of the database. Its changes are visible only to that transaction until commit time, when all changes become visible atomically to any transaction which begins at a later time. If transaction T1 has modified an object x, and another transaction T2 committed a write to x after T1’s snapshot began, and before T1’s commit, then T1 must abort.

Snapshot isolation can be hard to achieve with network partitions. Two alternatives:

  1. Transactional storage for geo-replicated systems (with trade-off of long fork anomalies)
  2. Read Committed

Read Committed:

Read uncommitted prevents dirty writes. It is totally available with network partitions.

Read uncommitted does not gurantee real-time constraints. E.g. strict serializability. Does not necessary require the per-process order between transactions. A process can observe a write, then fail to observe that same write in a subsequent transaction.

Improved Read Uncommitted consistency model by preventing dirty reads (preventing transactions reading from uncommitted writes)

Snapshot isolation does not enforce a total order on all transactions. Enforces partial order: operations within one transactions may interleave with operations from other transactions. –> write skew

Need Serializable snapshot isolation:

https://www.cockroachlabs.com/blog/serializable-lockless-distributed-isolation-cockroachdb/

Michael J. Cahill, Uwe Röhm, and Alan D. Fekete. Seri- alizable isolation for snapshot databases. In Proceedings of the 2008 ACM SIGMOD International Conference on Management of Data, SIGMOD ’08, page 729–738, New York, NY, USA, 2008. Association for Computing Machinery.

https://courses.cs.washington.edu/courses/cse444/08au/544M/READING-LIST/fekete-sigmod2008.pdf

Ref: https://jepsen.io/consistency/models/snapshot-isolation