Transactions & ACID Properties
Press Next → or use ← → arrow keys
The Story — The ATM That Lost ₹5,000
A database must treat those two steps as one indivisible unit — it either completes entirely or has no effect at all. That unit is a transaction.
A Transaction & Its Four Operations
A transaction is a sequence of one or more operations treated as a single, indivisible unit. It either commits (all changes permanent) or rolls back (no effect). There is no half-done state.
Committed or Aborted — there is no third outcome.
The Classic Fund Transfer
BEGIN TRANSACTION;
UPDATE accounts
SET balance = balance - 5000
WHERE acc_id = 'A';
UPDATE accounts
SET balance = balance + 5000
WHERE acc_id = 'B';
COMMIT;Abstract steps: Read(A) · A := A−5000 · Write(A) · Read(B) · B := B+5000 · Write(B) · Commit. If a crash strikes after Write(A) but before Write(B), ₹5,000 is deducted but never credited — the database is inconsistent. Atomicity is what prevents this.
The Transaction State Diagram
Active → Partially Committed → Committed → Terminated.
Active / Partially Committed → Failed → Aborted → Terminated.
Which Transitions Are Legal?
| Transition | Valid? | Reason |
|---|---|---|
| Active → Partially Committed | YES | After the final operation executes |
| Active → Failed | YES | Crash or error during execution |
| Partially Committed → Committed | YES | Changes flushed to stable storage |
| Partially Committed → Failed | YES | The final disk write can still fail |
| Committed → Active | NO | Commit is final — can't re-run it |
| Failed → Committed | NO | A failed transaction must be aborted, never committed |
"Committed is forever." A transaction can never go from Committed back to Active or Aborted — undoing it requires a brand-new compensating transaction.
The Four ACID Properties
Atomicity · Consistency · Isolation · Durability. Consistency is the goal; Atomicity, Isolation, and Durability are the mechanisms that achieve it.
Each Property, and Who Guarantees It
| Property | Promise | Guaranteed by |
|---|---|---|
| Atomicity | All operations succeed or none do — no partial execution | Transaction / recovery manager |
| Consistency | Moves DB from one valid state to another; totals add up | Application + DBMS |
| Isolation | Concurrent result equals some serial order | Concurrency-control manager |
| Durability | Committed changes persist through any later crash | Recovery manager (logs + stable storage) |
Partial execution → Atomicity. Broken rule / total mismatch → Consistency. Transactions seeing each other → Isolation. Committed data lost after a crash → Durability.
Atomicity — Without vs With
| Step | A | B |
|---|---|---|
| Start | 10000 | 2000 |
| Write(A) | 5000 | 2000 |
| 💥 CRASH | 5000 | 2000 |
| Result | 5000 | 2000 |
Total 12,000 → 7,000. ₹5,000 vanished.
| Step | A | B |
|---|---|---|
| Start | 10000 | 2000 |
| Write(A) | 5000 | 2000 |
| ↺ ROLLBACK | 10000 | 2000 |
| Result | 10000 | 2000 |
Total stays 12,000. Consistent state restored.
By undoing the half-finished transfer, atomicity guarantees the money supply stays balanced — the invariant "A + B is unchanged by a transfer" holds.
Why Run Transactions Concurrently?
A concurrent schedule is correct only if its outcome equals some serial execution of the same transactions. When it doesn't, one of the anomalies on the next slides has crept in.
Four Isolation Failures
The cure is concurrency control — locking or timestamp ordering — forcing conflicting transactions to take turns.
The Lost Update, Step by Step
Both transactions increment X = 100 by 10. Expected final value: 120.
| Time | T1 | T2 | X |
|---|---|---|---|
| t1 | Read(X) → 100 | 100 | |
| t2 | Read(X) → 100 | 100 | |
| t3 | X := 110 | 100 | |
| t4 | Write(X) | 110 | |
| t5 | X := 110 | 110 | |
| t6 | Write(X) | 110 |
T2 read X before T1 wrote it, so T2's write (110) overwrote T1's update. One of the two +10 increments simply disappeared.
Proper isolation (locking) makes T2 wait until T1 commits — producing the correct 120.
The gap of 10 is the "lost" update — a textbook Isolation violation.
Rapid-Fire Concept Check
| Question | Answer |
|---|---|
| Initial state of every transaction | Active |
| State after final op, before disk write | Partially Committed |
| All-or-nothing execution | Atomicity |
| Committed data survives a crash | Durability |
| Prevents concurrent interference | Isolation |
| Keeps the database in a valid state | Consistency |
| Makes changes permanent | Commit |
| Undoes all changes | Rollback / Abort |
| One update overwrites another | Lost Update |
Golden Rules of Transactions
All or Nothing, Forever, In Isolation
A transaction bundles many operations into one all-or-nothing unit that travels a strict lifecycle from Active to Committed or Aborted. The ACID properties keep that unit safe: atomic, valid, isolated, and durable — so a crash mid-transfer or a race between users can never leave the database lying.
Consistency is the promise; Atomicity, Isolation, and Durability are how the DBMS keeps it — next stop: serializability and how schedules are proven safe.
💳 End of tutorial · Press ← to review, or click Restart