What is a cascading abort in a database, how can releasing exclusive (write) locks before commit under basic two-phase locking cause one, and how does holding those locks until commit eliminate the problem?

## The three recoverability classes Serializability is about *isolation*; it says nothing about what happens when a transaction fails. A schedule can be perfectly conflict-serializable and still be impossible to recover from. The classic hierarchy, from weakest to strongest: - **Recoverable** — a transaction commits only *after* every transaction whose writes it read has committed. Guarantees you never have to un-commit something. - **Cascadeless (avoids cascading aborts, ACA)** — transactions only ever *read* data written by committed transactions. Stronger: no dirty reads at all, so no abort ever propagates. - **Strict** — transactions neither read nor **overwrite** an item written by an uncommitted transaction. Strongest of the three, and the one that makes before-image undo correct. Each implies the one above it. Strict 2PL delivers the strict class, which is where the name comes from. ## How basic 2PL produces a cascade Basic 2PL only requires acquire-before-release ordering; it lets a transaction drop a write lock in its shrinking phase, well before commit. Consider: ``` T1: lock-X(A) write A=5 unlock(A) ... more work ... ABORT T2: lock-S(A) read A=5 write B=A*2 ... T3: read B ... ``` T2 read a value that, after T1's rollback, never existed in any committed state. T2's computation is invalid, so T2 must abort. T3 read T2's output, so T3 must abort. In a real workload this fan-out follows the data-dependency graph and is bounded only by how many transactions touched the row and its descendants — a single failure, possibly a deadlock victim chosen at random, can wipe out a large amount of committed-looking work. The engine also has to *track* the read-from relationships to know whom to cascade to, which is bookkeeping nobody wants. ## The two harder problems underneath Cascades are the visible symptom; two deeper issues make early write-lock release untenable. **Non-recoverability.** Change the schedule so T2 commits before T1 aborts. Now the system is stuck: it has already durably promised T2's result to the client, and that result was derived from a write that is being undone. There is no correct action available. Recoverable schedules exist precisely to make this state unreachable. **Unsound rollback.** Engines undo a transaction by restoring the **before-image** of each row it changed (the physiological undo you find in ARIES-style recovery). Suppose A starts at 1, T1 writes A=5, releases the lock, and T2 then writes A=9. When T1 aborts, restoring T1's before-image sets A back to 1 — silently destroying T2's committed write. This is the *lost update on rollback* problem, and it is why the **strict** class forbids not just reading but **overwriting** uncommitted data. Avoiding it without strictness would require version-aware undo, i.e. rebuilding a good part of MVCC. ## What holding exclusive locks to commit buys Strict 2PL says: keep every exclusive lock until commit or abort. Because a write lock conflicts with both shared and exclusive requests, no other transaction can read or overwrite the row while the writer is in flight. Therefore: - Every value any transaction reads was written by a committed transaction → **cascadeless**, so aborts never propagate and no read-from tracking is needed. - No one can overwrite your uncommitted row → **before-image undo is always correct**, so rollback is a local, bounded operation. - Commit ordering is safe → **recoverable**. The cost is lock hold time: the write lock now lives from first modification through commit, including the fsync of the commit record. That is why long transactions and slow commits hurt a lock-based engine so much — the tail of the commit path is *inside* the critical section. ## Why this is not an isolation-level knob The practically important consequence: engines keep write locks to commit even at READ COMMITTED and READ UNCOMMITTED. Weakening isolation relaxes the **read** side (how long shared locks are held, or whether they are taken at all); the write side stays strict because relaxing it would break rollback and recovery rather than merely permitting an anomaly. If a candidate says "at READ UNCOMMITTED nothing is locked", that is the misconception — dirty *reads* are allowed, dirty *writes* are not, at any level. MVCC engines reach the same guarantee by different means: a writer creates a new row version that is invisible to everyone until its transaction commits, so readers automatically see only committed data and abort never cascades — the write side is still effectively locked (row-level write locks / first-updater-wins), while readers are exempted because they never need the lock at all. ## Answering well Define the cascade, show the two-line schedule that produces it, then escalate to the two things that actually force implementations' hands — non-recoverable commits and before-image undo destroying a later write — and finish with: this is why write locks are held to commit at every isolation level, and why "strict" in strict 2PL refers to the strict schedule class.