Page 6: Transaction Failures and Recovery

Recoverable Schedules

Rule: Transaction can only commit AFTER all transactions it depends on have committed.

For transactions Ti and Tj , if Tj reads a value written by Ti , then Tj cannot commit before Ti commits. This ensures the atomicity property during concurrent execution.

Example - Recoverable:

T₁: write(A), commit
T₂:           read(A), commit

T₂ commits after T₁ commits = Safe

Example - Non-Recoverable:

T₁: write(A)      , abort
T₂:          read(A), commit

T₂ already committed with bad data = Disaster!

Cascadeless Schedules

Rule: Transaction can only read data that has been committed.

Example - Cascadeless:

T₁: write(A), commit
T₂:                 read(A), write(B), commit
T₃:                                   read(B), commit

Each transaction reads only after previous one commits.

Example - Cascading Abort:

T₁: write(A)
T₂:          read(A), write(B)  
T₃:                            read(B), write(C)
T₁: abort ← This forces T₂ to abort, which forces T₃ to abort

One failure causes chain reaction!

Schedule Hierarchy

Serial Schedules
    ⊆ Conflict Serializable  
        ⊆ View Serializable
            ⊆ Recoverable
                ⊆ All Possible Schedules

Cascadeless ⊆ Recoverable (cascadeless schedules are always recoverable)

Updated on