Chapter 7: Transactions & ACID Guarantees

Transactions & ACID Guarantees on Transactions provides a deep dive into how data-intensive applications maintain reliability and simplify fault handling by grouping database operations into logical, all-or-nothing units that either fully commit or fully abort (rollback). Historically, the safety assurances of these mechanisms are summarized by the ACID acronym, which stands for Atomicity, Consistency, Isolation, and Durability. Atomicity ensures that transactional changes are wholly completed or entirely discarded, effectively providing an abortability feature in the event of partial failures like crashes or network interruptions. Consistency, in the ACID context, refers to the application-defined invariants that must hold true for the database to be in a “good state,” a responsibility shared between the database and the application logic. Isolation dictates that concurrently executing transactions must not interfere with one another, preventing race conditions, ideally matching the strongest standard, serializability. Durability promises that once a transaction successfully commits, its data persists, typically through writes to nonvolatile storage or successful replication across multiple nodes. Due to performance concerns, many databases employ weak isolation levels, which protect against some concurrency issues but not all. The most common level is Read Committed, which guarantees that a client will not see uncommitted data (no dirty reads) or overwrite uncommitted data (no dirty writes). A stronger and highly practical alternative is Snapshot Isolation, which prevents read skew or nonrepeatable reads by ensuring each transaction operates on a consistent snapshot of the database state from the moment the transaction began. Snapshot isolation is commonly implemented using Multi-Version Concurrency Control (MVCC), where the system retains multiple versions of data objects to allow readers and writers to proceed without blocking one another. Even stronger protections are necessary to prevent issues like lost updates, which occur during concurrent read-modify-write cycles, and write skew, a subtle anomaly where a transaction makes a decision based on a premise that another concurrent transaction then invalidates, often involving phantoms—writes that change the result set of a prior search query. To achieve true serializability, which eliminates all these race conditions, databases primarily use one of three methods: Actual Serial Execution (viable for fast, short, single-partition, in-memory transactions via stored procedures); Two-Phase Locking (2PL), a pessimistic approach where writers block readers and vice versa using shared and exclusive locks held until commit, often suffering from unstable latency and deadlocks; or Serializable Snapshot Isolation (SSI), an optimistic concurrency control technique that uses MVCC combined with mechanisms to detect serialization conflicts upon commit, offering better overall performance and scalability than traditional 2PL.