ACID Transactions
This chapter explains the ACID properties of a transaction: atomicity, consistency, isolation, and durability. It shows each one through a new case study, Dining Dollars, a prepaid lunch balance for a high school, and it ends with why these properties matter to a software designer.
After reading this chapter, you should be able to:
- Read the Dining Dollars schema and explain why the balance is stored on the account when it can be computed from the ledger
- Identify the two writes in a purchase, explain why they must succeed or fail together, and explain what happens when the database refuses one of them
- Explain why a database changes data in memory first and what it writes to disk before it says “committed”
- Trace a purchase and a reload running at the same time, explain what a lost update is, and show how locking the row at the read prevents it
- Define atomicity, consistency, isolation, and durability, explain why consistency differs from the other three, and explain why these properties matter to a designer