Transactions & Concurrency

Serializable Transactions

Serializable isolation permits only outcomes equivalent to a serial execution. Engines achieve it through serial execution, strict two-phase locking, SSI or other validation, trading blocking or aborts for a tractable correctness model.
  • Serializable is an outcome guarantee.
  • Strict 2PL prevents cycles by blocking.
  • SSI detects dangerous dependencies.
  • Aborts are part of the API.
  • Serializable does not cover the outside world.
Serializable implementation families
FamilyPrimary response to conflictOperational consequence
Serial executionQueue workNo concurrency inside partition; transactions must be short
Strict 2PLWait on incompatible locksDeadlocks and lock footprint
SSI / optimistic validationRun then abort dangerous structureMore concurrency; retry pressure
Deterministic orderingPreorder operationsNeeds known read/write set or coordination
On-call trace under serializable
Start: A=true, B=true; invariant at least one on call.
T1 and T2 read both rows; T1 proposes A=false; T2 proposes B=false.
Serializable outcome: one order may commit; the other must wait and see the new state or abort.
Both may not commit with final A=false, B=false.

PostgreSQL Serializable uses SSI over snapshots and reports serialization failures. Oracle Serializable uses transaction-level read consistency and rejects certain conflicting updates. SQL Server Serializable primarily uses key-range locking. Equal labels, different mechanisms and failure surfaces.