Understanding Transaction Isolation for App Developers
summary
Explains PostgreSQL MVCC so writers never block readers and details three concrete anomalies with numbers: IMAX price $10 plus $5 twice becomes $20 (lost update), seating capacity 100 with 98 sold yields final −2 after two concurrent purchases (serialization anomaly), dashboard counts 10 → 11 and sums $100 → $108 (non repeatable read). Shows that read committed takes a fresh snapshot per SELECT, repeatable read uses exec_update to prevent lost updates and phantoms, and serializable uses predicate locks and check target for conflicts and may abort transactions.
AI-written summary · about
chapters (11)
- 0:00Introduction
- 2:40Agenda
- 3:08What is MCC
- 9:30Example
- 11:55Behavior
- 12:33Nonrepeatable Debt
- 14:13Serialization
- 16:08Review
- 16:58Isolation Levels
- 24:04Nonrepeatable Red
- 25:38Best Practices
related talks
45mTransactions and Concurrency Control Patterns
41mTransactions: myths, surprises and opportunities
41mConcurrency, Scalability and Transactions -- Myths and Surprises
50mExplaining the PG concurrency control mechanisms using rollercoasters
49mConcurrency Deep-Dive
50mWe have multiple concurrent versions of this title trying to understand MVCC
43mBeing Transactional in 2019 — What Does That Actually Mean?
47mBeing transactional in 2019 - what does this actually mean?