Module 18 · Transactions and concurrency · Lesson 1 of 5
Transactions and schedules
The formal model behind ACID: transactions as sequences of reads and writes, transaction states, schedules that interleave them, and the anomalies interleaving causes (lost update, dirty read, unrepeatable read).
Why it matters
The System Design track's ACID lesson describes what transactions promise. This module explains how a DBMS keeps that promise while running thousands of transactions at once. Everything starts with a precise model: a transaction as a list of reads and writes, and a schedule as one way of interleaving several transactions. The anomalies and schedule properties in this lesson are standard exam material, and they are the vocabulary for explaining every concurrency bug you will meet in production.
The idea
A transaction is a sequence of operations that the DBMS treats as one unit. For analysis we reduce it to reads R(X) and writes W(X) of data items, ending with commit (C) or abort (A). Transfer ₹100 from account A to B:
T1: R(A), A = A − 100, W(A), R(B), B = B + 100, W(B), C
Transaction states
Schedules
A schedule is an ordering of the operations of several transactions that preserves each transaction's own order. A serial schedule runs transactions one after another with no interleaving; it is always correct but wastes the machine, because one transaction waiting for disk or the user blocks everyone. A concurrent (interleaved) schedule overlaps them for throughput. The question this module answers is which interleavings are safe.
What goes wrong when interleaving is unrestricted
| Anomaly | Interleaving | Result |
|---|---|---|
| Lost update (write-write) | T1 reads A=500, T2 reads A=500, T1 writes 400, T2 writes 450 | T1's update vanishes: A should be 350 |
| Dirty read (write-read) | T1 writes A=400, T2 reads 400, T1 aborts | T2 acted on a value that never existed |
| Unrepeatable read (read-write) | T1 reads A=500, T2 writes and commits A=400, T1 reads A again | T1 sees two different values in one transaction |
| Phantom | T1 counts rows matching a condition, T2 inserts a matching row, T1 counts again | A new row appears mid-transaction |
| Incorrect summary | T1 sums all balances while T2 moves money between accounts | The total counts some money twice or not at all |
Recoverability: surviving aborts
Correct interleaving is not only about final values; an abort must be undoable without breaking other transactions.
- 1
Recoverable
If T2 reads a value written by T1, then T2 commits only after T1 commits. Otherwise T1 could abort after T2 has committed a result based on T1's data, and nothing can fix it. Every acceptable schedule must be recoverable. - 2
Cascadeless (avoids cascading aborts)
Transactions read only committed data. Without this, T1's abort forces T2 (which read T1's write) to abort, then T3 (which read T2's), a cascading rollback that wastes work. - 3
Strict
No transaction reads or overwrites a value until the transaction that last wrote it has committed or aborted. Undo is then simply restoring before-images. Strict two-phase locking, next lessons, produces strict schedules, which is why real databases use it.
Each property implies the one above it: strict schedules are cascadeless, and cascadeless schedules are recoverable.
Isolation levels as a contract
SQL's isolation levels (read uncommitted, read committed, repeatable read, serializable) are defined by which of these anomalies they permit, as the System Design ACID lesson tabulates. The rest of this module explains the mechanisms behind them: serializability theory defines "correct", and locking, timestamps and multiversioning are three ways to enforce it.
Trade-offs
Serial execution is trivially correct and unusably slow; unrestricted interleaving is fast and wrong. Every concurrency control scheme picks a point between, allowing more interleaving at the cost of more bookkeeping, or fewer anomalies at the cost of more waiting and aborts. Recoverability is not optional; cascadelessness and strictness are chosen because they keep recovery simple.
In an interview
Use the formal names with a concrete example: "Two clerks booking the last seat is a lost update: both read one seat free, both write zero. A dirty read would be booking based on a cancellation that was then rolled back. The DBMS prevents both by producing serializable, strict schedules, usually with strict two-phase locking or MVCC."
Check yourself
In a schedule, T2 reads a value written by T1, and T2 commits before T1 does. T1 then aborts. Which property did the schedule violate?