Consider the following ordering schedule — S’ of transactions: `` T1 : R(A); T1 : A := A + 5; T1 : commit; T2 : R(B); T2 : B := B + 5; T3 : R(C); T3 :

Question

Consider the following ordering schedule —
**S’** of transactions:

```
T1 : R(A);  
T1 : A := A + 5;  
T1 : commit;

T2 : R(B);  
T2 : B := B + 5;

T3 : R(C);  
T3 : C := C + 5;  
T3 : C := C + 5;

T4 : R(A);  
T4 : A := A + 5;  
T4 : R(D);  
T4 : D := D + 5;  
T4 : commit;

T2 : commit;  
T3 : commit;
```

Let the initial value of **A = B = C = D = 0**.
The system follows **log-based recovery process** of *immediate database modification*.

The assumption is the concurrency control system uses **strict 2PL**, and all transactions share a **common disk buffer** and **single log**.

**Explain what happens during the recovery process if a failure occurs at `T2 : commit` statement.**

Accepted Answer

Given schedule S' with immediate modification, strict 2PL, common buffer/log, initial A=B=C=D=0. Sequence: T1 R(A) A=A+5 commit (A=5 logged), T2 R(B) B=B+5 (B=5 uncommitted), T3 R(C) C=C+5; C=C+5 (C=10 uncommitted, but two increments? note C incremented twice to 10), T4 R(A) A=A+5 (A reads 5, writes 10), R(D) D=D+5 commit (D=5 committed), then T2 commit then T3 commit.

Immediate modification means uncommitted updates may be written to disk before commit (steal), so undo needed. Strict 2PL holds X locks till commit, so T2 holds B, T3 holds C, T4 holds A,D till commit.

Failure occurs at T2:commit statement (T2 attempting commit, T4 already committed, T1 committed, T2 and T3 have not fully committed at failure point).

Recovery (UNDO/REDO via log analysis):
Log contains <T1 start>, <T1, A, 0,5>, <T1 commit>, <T2 start>, <T2, B,0,5>, <T3 start>, <T3, C,0,5>, <T3,C,5,10>, <T4 start>, <T4,A,5,10>, <T4,D,0,5>, <T4 commit> (steal may have flushed B,C,A). At failure, checkpoint analysis:

REDO: T1 and T4 are committed (and flushed before failure) - redo their updates to ensure durability (A=10? Actually T1 A=5 then T4 overwrote A=10, so final A=10, D=5).
UNDO: T2 and T3 are active/uncommitted at crash (T2 commit not completed, T3 not committed). Since immediate modification, their updates may be on disk and must be undone: B=0 (undo B 0->5), C=0 (undo C chain 0->5->10). Using undo log records in reverse.

If strict 2PL buffer sharing noted: no dirty read but dirty writes possible via buffer. After recovery, DB reflects only committed transactions: A=10, D=5, B=0, C=0, then T2/T3 will be restarted/aborted. Some textbooks show T2's commit record not yet written, so T2 also undone. Result: T1 and T4 persist.

Similar questions

PYQDeck for Android