Serializable snapshot isolation

Imagine two independent availability-controller rows, A and B, both marked active. Each controller transaction reads both rows and disables its own row only if another controller remains active. Starting from the same snapshot, each sees two active rows and writes a different row. Their write sets do not overlap, yet together they leave no active controller. A serial execution of these particular transactions would leave one active, because the second transaction would observe the first change and decline to disable itself.

This is write skew: the conflict is in what the transactions read and decide, rather than two writers replacing the same record. Predicate reads can create analogous dependencies when a concurrent transaction inserts or removes matching rows. Checking only write-write overlap misses them. Every decision-critical query must participate in the intended transaction and isolation regime. An administrative script or a second service using weaker guarantees can invalidate an application-level argument that assumed all relevant changes followed one discipline.

A read-write antidependency points from a transaction that read an older version or predicate result to a concurrent transaction whose change it did not observe. In a serialization graph, such an edge constrains the apparent serial order. Under snapshot isolation, a nonserializable cycle contains adjacent read-write antidependencies. SSI monitors dangerous structures of this form, with concurrency and commit-order reasoning, rather than simply aborting whenever any ordinary service graph has a cycle or any two transactions touch the same table.

A dangerous structure can exist without a complete serialization cycle, so conservative detection can produce serialization failures for executions that might otherwise have been serializable. The exact implementation uses additional rules to reduce unnecessary aborts while preserving safety. Do not interpret every rejection as proof that committed data was already corrupted. Also distinguish SSI’s read-dependency tracking from blocking locks: recording a predicate dependency need not block a writer in the way an exclusive lock does. Performance and memory costs still exist even without that blocking.

On a serialization failure, retry the entire logical database transaction with fresh reads and decision logic. Repeating only the final update can preserve the stale condition that caused the failure. Keep nontransactional side effects outside automatic retry or protect them with an explicit idempotency and delivery design. Apply bounded backoff and a retry budget so contention does not create an unbounded feedback loop. Monitor failures by query shape and contention hotspot while checking that all eventually accepted outcomes satisfy the invariant.

The probability lab illustrates only a test assumption. Reset, set success probability p to 0.2 and trials n to 3, predict the probability of at least one marked outcome, then Step. This exact binomial distribution treats outcomes as independent with one fixed probability; use a marked outcome to mean an assumed retry in three fixed test attempts. It does not model SSI’s dependency graph or claim real retries are independent. Shared hot records and retry feedback are reasons the real distribution can differ.