What problem does it solve?
Transaction isolation choices determine what concurrent transactions can observe of each other, and incorrect isolation levels allow correctness bugs like dirty reads, non-repeatable reads, phantoms, write skew, and lost updates.
Core Features & Use Cases
- Isolation level and anomaly mapping: Covers the five practical levels (read uncommitted, read committed, repeatable read, snapshot isolation, serializable) and the anomalies each can admit or eliminate.
- Standard critique and implementation reality: Explains the Berenson et al. (1995) critique and why “serializable” and other names are not reliably equivalent across databases.
- Implementation mechanisms: Distinguishes locking-based approaches from MVCC, including Postgres Serializable Snapshot Isolation (SSI) and its abort/retry behavior.
- A workload-driven selection procedure: Guides teams to enumerate the anomalies their workload cannot tolerate, then choose the lowest isolation level that prevents them, adding explicit locking only where needed.
Quick Start
Tell the agent: “Given my workload’s correctness invariants and the database engine (e.g., Postgres or MySQL), what isolation level should I choose to prevent dirty reads, non-repeatable reads, phantoms, write skew, and lost updates, and what retry or locking steps do I need?”