Log-Based Recovery (Immediate DB Modification + Strict 2PL): Failure at T2 : commit

We analyze a log-based recovery system under immediate database modification (i.e., updates are applied to the database pages right away) together with strict 2PL (so updates are not made durable until the transaction is allowed to release locks, but pages/updates may still be in memory or on disk depending on the buffer flush). A failure occurs at the statement T2 : commit, meaning the commit record may or may not have reached the stable log; the safe recovery behavior is determined by which log records are guaranteed to be stable at crash time.

log-based recovery immediate modification strict 2PL commit record redo/undo.

Because updates are immediate, at crash time the database might already reflect some changes from T1 and T2 (and possibly other transactions depending on timing), even if they were not committed.

Ordering schedule S′ (from the prompt)

• T1: R(A); A := A + 5; commit;
• T2: R(B); B := B + 5; commit; ← failure happens here
• T3: R(C); C := C + 5; C := C + 5; commit;
• T4: R(A); A := A + 5; R(D); D := D + 5; commit; All start with A=B=C=D=0. There is a single log and a common disk buffer.

Key recovery classification at the time of the crash

At the moment of failure at T2 : commit, the system must treat:

• T1 as committed (its commit statement occurred earlier)
• T2 as possibly not committed (crash occurs during/at commit)
• T3 and T4 as uncommitted with respect to the crash (their commits occur after)

Therefore, the standard log-based recovery idea is:

• Redo all updates from transactions that are known to have committed (stable commit log record present).
• Undo all updates from transactions that are not known to have committed (i.e., no stable commit log record).

This yields the correct final state regardless of whether some updates from uncommitted transactions were written to disk/buffer.

Step-by-step recovery outcome (what happens on disk pages)

Under immediate database modification, the database might already contain:

• T1’s update to A
• possibly T2’s update to B (since it happened before T2 : commit is reached)
• possibly T3’s update to C
• possibly T4’s updates to A and D

However, recovery correctness depends on log status, not on what is on disk at crash.

We can reason transaction by transaction.

1) Transaction T1

T1 updates: A := A + 5 then commits earlier.

So T1 is committed at crash time. Therefore, its effects must be present after recovery, achieved by redo (or by leaving them if already present, depending on the precise recovery algorithm, but the net effect is “keep T1’s update”).

• Initial: A=0
• After T1: A=5

So we expect: A contains the contribution from T1: +5. redo/undo

2) Transaction T2 (failure at its commit statement)

T2 updates: B := B + 5, then reaches commit where the crash occurs.

Since the crash occurs at T2 : commit, the commit record for T2 may be absent from the stable log (worst-case) or may be present (best-case). Robust recovery typically assumes it is not safe to treat T2 as committed unless the commit record is stable.

Thus, recovery treats T2 as uncommitted and performs undo of its updates.

• T2 update was: B := B + 5 (based on the current value of B at the time of execution; initial B is 0)
• Undo will restore B back to the pre-T2 value, i.e., subtract the +5 effect.

Net effect: B becomes 0 after recovery.
This is the crucial behavior: even if B := B + 5 is already on disk because updates were immediate, undo removes it.

undo.

3) Transaction T3

T3 is not committed at crash time (its commit is after crash).

Its updates:

• C := C + 5 twice
  Starting from initial C=0, it would have produced C=10 if not rolled back.

Recovery will undo all T3 effects, returning:

• C back to 0.

compensation log record.

4) Transaction T4

T4 is also uncommitted at crash time.

Its updates:

• A := A + 5
• D := D + 5

So if those updates reached disk before crash, they would have temporarily changed:

• A by +5
• D by +5

But recovery will undo them, returning:

• A to whatever state remains after committed transactions only
• D back to 0

Net effect: A retains only committed contributions (from T1), and D becomes 0.

Consolidated final answer (net effect)

Given the above, after recovery:

• A: only T1’s committed update remains
  $A = 0 + 5 = 5$
• B: T2 is treated as uncommitted at crash-at-commit, so its update is undone
  $B = 0$
• C: T3 is uncommitted, undo both $+5$ updates
  $C = 0$
• D: T4 is uncommitted, undo $+5$
  $D = 0$

Therefore, the post-recovery database state is: $A=5,\; B=0,\; C=0,\; D=0$