Cascadeless Schedule

Motivation: What Recoverability Alone Doesn't Prevent

A schedule can be perfectly recoverable (23.7) and still cause a painful chain reaction if a transaction aborts. Consider three transactions, all reading a chain of uncommitted writes: T1 writes A (uncommitted), T2 reads T1's dirty A and writes B (uncommitted), T3 reads T2's dirty B. If T1 now aborts, T2's write was based on invalid data, so T2 must also abort — and now T3's read was based on T2's invalid data, so T3 must abort too. This chain reaction of forced rollbacks is called cascading rollback (cascading abort), and while it doesn't violate recoverability by itself, it is expensive and something stronger schedules avoid entirely.

Definition

A schedule is cascadeless (avoids cascading rollback) if every transaction is only allowed to read a data item after the transaction that last wrote it has already committed — not merely before the reader itself commits (which is all recoverability requires), but before the reader even performs the read. In other words: no dirty reads are permitted at all.

Worked Example — Recoverable but NOT Cascadeless

1. W1(A)          -> A=900 (uncommitted)
2. R2(A)          -> T2 reads 900 -- BEFORE T1 has committed (a dirty read)
3. COMMIT1        -> T1 commits
4. COMMIT2        -> T2 commits, after T1 (satisfies recoverability)

This schedule is recoverable (T1 commits at step 3, before T2 commits at step 4). But it is not cascadeless, because T2's read at step 2 happened before T1's commit at step 3 — T2 performed a dirty read. If T1 had aborted instead of committing at step 3, T2 (already having read the dirty value, though not yet committed) would be forced to also abort — a cascading rollback. The schedule got lucky that T1 committed, but the schedule structure itself permitted the dangerous dependency.

Worked Example — Cascadeless

1. W1(A)          -> A=900 (uncommitted)
2. COMMIT1        -> T1 commits FIRST
3. R2(A)          -> T2 reads 900, only AFTER T1 already committed
4. COMMIT2        -> T2 commits

Now T2's read (step 3) only happens after T1's commit (step 2) — there is no window in which T2 could read a value that might later be rolled back. Even if some other transaction later aborts, T2 can never be forced to cascade, because it never read anything uncommitted.

Every Cascadeless Schedule Is Recoverable

Notice cascadelessness is strictly stronger than recoverability: if Tj only ever reads Ti's data after Ti commits, then trivially Ti commits before Tj even reads (let alone commits) — satisfying recoverability automatically. But the reverse doesn't hold, as the first worked example shows (recoverable, not cascadeless).

Edge Cases

• Cascadelessness only restricts reads; it says nothing about two transactions both writing the same item before either commits (a blind-write scenario) — that additional restriction is what the even-stronger strict schedule (23.9) adds.
• A cascading rollback can, in the worst case, ripple through many transactions (T3 depends on T2 depends on T1...); cascadelessness prevents the entire chain by cutting it off at the very first link (no dirty reads permitted anywhere).
• Cascadelessness does not eliminate transactions waiting — T2 may simply have to block until T1 commits, which is exactly how lock-based protocols implement it (holding read locks until the writer's commit).

Key Takeaways / Interview Angle

• Q: What extra guarantee does cascadeless add over merely recoverable? It moves the "must happen after Ti commits" requirement from Tj's commit (recoverable) to Tj's read itself (cascadeless) — eliminating dirty reads entirely, not just eventually recovering from them.
• Q: Why do we care about cascading rollback if the schedule is already recoverable? Recoverability only guarantees the database can eventually be fixed; it doesn't prevent an expensive, unpredictable chain of forced aborts across many transactions in the meantime — cascadelessness avoids the mess altogether.