---
title: "Transaction recovery techniques"
subject: "Distributed System"
chapter: 8
key: "semester_7/distributed_system:transaction-recovery"
source: https://www.bctengineer.com/q/semester_7/distributed_system/transaction-recovery
site: BCT Engineering
---

# Transaction recovery techniques

Distributed System · Chapter 8: Transaction and Concurrency Control

- Asked in: Model question
- Video: [DS40: Distributed deadlocks , Transaction recovery in Distributed System](https://www.youtube.com/watch?v=wEfou6tgFYo) — University Academy
- Answer checked by Claude Opus 5.5 (high effort) on 2026-10-14
- Page: https://www.bctengineer.com/q/semester_7/distributed_system/transaction-recovery
- Whole chapter: https://www.bctengineer.com/md/semester_7/distributed_system/chapter-8

## Question

Explain transaction recovery techniques with example (log file, shadow paging etc.).

## Short answer

Log-based recovery uses write-ahead logging with before/after images. On failure, undo uncommitted transactions and redo committed ones, e.g., T1 committed is redone, T2 without commit is undone. Shadow paging copies page tables; updates go to new pages; commit atomically swaps tables, abort discards new pages. Shadow avoids undo/redo but scatters pages.

## Answer

Recovery brings the data back to a consistent state after a failure or abort, using redundant information kept on stable storage.

#### Log-based recovery
A **log (journal)** records every update before it is applied to the database (**write-ahead logging**). Each record holds the transaction id, the object, the old value (before-image) and the new value (after-image); there are also *start*, *commit* and *abort* records.
- **Undo**: for an aborted or uncommitted transaction, the old values are restored from the log, scanning backwards.
- **Redo**: for a committed transaction whose updates may not have reached disk, the new values are re-applied, scanning forwards.
- **Checkpoints** in the log limit how far back recovery has to scan.

Example: the log holds *<T1 start>, <T1, A, 100, 150>, <T1 commit>, <T2 start>, <T2, B, 20, 40>*, and then the system crashes. On recovery, T1 is redone (A = 150), and T2, which has no commit record, is undone (B = 20).

#### Shadow paging
The database is a set of pages reached through a **page table**. When a transaction starts, a copy of the page table, the **shadow page table**, is kept unchanged. Updates are written to new pages, and only the *current* page table points to them. On commit, the current table atomically replaces the shadow table (a single pointer switch); on abort, the current table is discarded and the shadow table is still valid.
- No undo or redo is needed, and recovery is quick.
- Disadvantages: pages become scattered on disk, garbage collection is needed, and supporting many concurrent transactions is harder.

#### Comparison
Logging allows fine-grained, concurrent updates and is the standard method; shadow paging is simpler but suits systems where only one transaction updates at a time.

## Check yourself

The answer's key points as multiple-choice questions, with the correct option and why.

1. What does write-ahead logging require?
   A. Updates are logged before being applied to the database
   B. The log is written after the commit
   C. Only commit records are logged
   D. Logs are kept in volatile memory
   Answer: A. Logging first lets recovery undo or redo updates after a crash. (Key point: Write-ahead logging)

2. After a crash, a transaction with a commit record whose updates may not have reached disk is:
   A. Undone
   B. Redone
   C. Ignored
   D. Restarted from scratch
   Answer: B. Committed transactions are redone by reapplying after-images, scanning forward. (Key point: Undo vs redo)

3. Log: <T1 start>, <T1,A,100,150>, <T1 commit>, <T2 start>, <T2,B,20,40>, then a crash. After recovery, A and B are:
   A. A=100, B=40
   B. A=150, B=40
   C. A=150, B=20
   D. A=100, B=20
   Answer: C. T1 committed so it is redone (A=150); T2 has no commit so it is undone (B=20). (Key point: Log example)

4. How does shadow paging commit a transaction?
   A. It replays the log forward
   B. The current page table atomically replaces the shadow page table
   C. It copies all pages back to the original location
   D. It deletes the current table
   Answer: B. One pointer switch makes the new pages the database; abort just discards the current table. (Key point: Shadow paging commit)

## Related in Distributed System

- [Distributed deadlock and recovery](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Adistributed-deadlock-note) — Distributed System, chapter 8, asked 3×
- [K-fault tolerant system; recovery](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Ak-fault-recovery) — Distributed System, chapter 9

## Related in other subjects

- [Recovery from log: deferred vs immediate](https://www.bctengineer.com/question.md?key=semester_6%2Fdatabase_management_system%3Alog-recovery-deferred-immediate) — Database Management System, chapter 8
- [Random access file transaction processing](https://www.bctengineer.com/question.md?key=semester_3%2Fobject_oriented_programming%3Arandom-access-transaction) — Object Oriented Programming, chapter 8
- [Compaction vs coalescing; paging; TLB](https://www.bctengineer.com/question.md?key=semester_6%2Foperating_system%3Acompaction-coalescing-paging-tlb) — Operating System, chapter 4
