Recoverable Schedule

Why This Matters Beyond Serializability

Serializability (23.4/23.5) only asks "does this schedule's result match some serial order?" It says nothing about what happens when a transaction aborts. Real transactions can and do abort — a constraint violation, a deadlock victim, an explicit ROLLBACK. Recoverability, cascadelessness, and strictness (this topic and the next two) form a separate hierarchy that governs how safely a schedule can handle aborts.

Definition

A schedule is recoverable if, whenever a transaction Tj reads a data item previously written by transaction Ti, Ti must commit before Tj commits. Equivalently: no transaction is allowed to commit until every transaction it "depends on" (read dirty data from) has already committed.

Worked Example — Recoverable (T1 commits before T2)

Using A = 1000 (T1 withdraws ₹100, T2 later reads A):

1. R1(A)          -> A=1000
2. A = 1000-100
3. W1(A)          -> A=900 (uncommitted)
4. R2(A)          -> T2 reads 900 (T1's uncommitted write)
5. COMMIT1        -> T1 commits
6. COMMIT2        -> T2 commits, AFTER T1 committed

T2 read a value written by T1 (step 4), and T1 committed (step 5) before T2 committed (step 6) — this satisfies recoverability. Even though T2 read T1's data before T1 committed, by the time T2 itself commits, T1's fate is already sealed (committed), so T2's commit is never "invalidated" retroactively.

Worked Example — NOT Recoverable

Now suppose T1 aborts instead of committing, after T2 already committed:

1. W1(A)          -> A=900 (uncommitted)
2. R2(A)          -> T2 reads 900
3. COMMIT2        -> T2 commits, based on T1's uncommitted value
4. ABORT1         -> T1 rolls back; A reverts to 1000

T2 already committed at step 3, believing A=900 is a permanent value. When T1 aborts at step 4, the value T2's commit was based on turns out to never have existed. Because T2 has already committed, it cannot be undone — this makes the whole schedule irrecoverable. The database is now in an inconsistent, unrepairable state: T2's committed result depended on data that logically never existed.

The Practical Consequence

An irrecoverable schedule is unacceptable in any real system — once a transaction commits, its effects must be permanent (durability), so if the value it committed on is later discovered to be phantom (because the source transaction aborted), there's no way to fix it without violating durability. This is why every serious DBMS's concurrency control (usually via locking, delaying a transaction's commit until its "dependencies" have resolved) enforces recoverability as a bare minimum requirement — separate from, and in addition to, enforcing serializability.

Edge Cases

• Recoverability says nothing about when Tj reads Ti's data (before or after Ti's commit) — only about the relative order of their commits. This is what distinguishes it from the stricter cascadeless property (23.8).
• A schedule where Ti never commits at all (it eventually aborts) and Tj never reads anything Ti wrote is trivially recoverable — recoverability constraints only kick in when an actual read-from dependency exists.
• If Ti aborts before Tj ever reads its dirty data, there's no dependency to worry about — Tj simply never sees the uncommitted value.

Key Takeaways / Interview Angle

• Q: What specifically makes a schedule irrecoverable? A transaction Tj commits after reading data from Ti, but Ti later aborts — Tj's already-permanent commit is now based on data that was rolled back.
• Q: Is recoverability a stronger or weaker guarantee than serializability? They are orthogonal/independent concerns — a schedule can be conflict-serializable yet irrecoverable, or recoverable yet not serializable; production systems must guarantee both.