transaction-isolation

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?”