What's changed: Initial version
4.1Transactions and ACID properties
Covers the ACID properties—atomicity, consistency, isolation, and durability—that make up a transaction, and how transaction boundaries are designed with BEGIN/COMMIT/ROLLBACK, building the judgment needed to preserve business-process integrity.
For an application developer designing a bank transfer or an e-commerce order-confirmation process, deciding "where a transaction should start and end"—the transaction boundary—is a critical judgment that determines the integrity of business data. A boundary drawn too narrowly can leave only part of an update applied, causing inconsistency; one drawn too broadly extends lock-holding time and makes other processing wait. This section builds the judgment needed to decide how to draw a transaction boundary, grounded in the ACID design principles.
4.1.1The four ACID properties
- Atomicity means the sequence of updates in a transaction is either applied in full or not applied at all. It is finalized with COMMIT, and if an abnormality occurs partway through, ROLLBACK undoes all the changes. Atomicity is what prevents a half-finished state such as "the withdrawal succeeded but the deposit failed" in a transfer.
- Consistency means the database continues to satisfy its defined integrity constraints (primary keys, foreign keys, check constraints, etc.) both before and after a transaction executes. Isolation means that multiple concurrently executing transactions cannot see each other's intermediate states, guaranteeing a result as if the transactions had run one at a time in some order (detailed in the next two sections). Durability means that once a transaction has completed COMMIT, its changes remain reliably on non-volatile storage such as disk even if a failure occurs immediately afterward.
Continue reading — free sign-up
You're reading the free preview. Sign up free to read this section in full, plus every chapter (including 4+) and all questions.

