Deferred & Immediate Update
Crash recovery mechanisms ensure that a database remains consistent and reliable, even when unexpected failures occur. Two common strategies used in logging and recovery are Deferred Update and Immediate Update. These approaches define when the actual data is written to the database and how the recovery handles different transaction states.
Â
1. Deferred Update
In the Deferred Update approach, changes made by a transaction are not applied to the database until the transaction successfully completes (i.e., until it commits). All the changes are first recorded in the log, and only after a commit do they get written to the database.
Â
How it works:
- Transaction begins → Log records are written (not database)
- Upon COMMIT → All changes are applied to the database
- If a crash occurs before commit, nothing is written to the database, so no rollback is needed
Â
Characteristics:
- Simple to recover: only committed transactions are redone
- Rollback is easy because no partial changes exist in the database
- Efficient for systems where transactions often abort before commit
Â
Example:
Recovery Strategy:
- Redo all operations of committed transactions using the log
- Ignore uncommitted transactions (no undo needed)
2. Immediate Update
With the Immediate Update strategy, changes made by a transaction can be written to the database before the transaction commits. However, the write-ahead logging (WAL) rule must be followed: the change must be logged first, then the database can be updated.
Â
How it works:
- Transaction begins → Changes are logged → Changes can be applied immediately to the database
- If the transaction commits, no further action needed
- If it fails or the system crashes, undo operations are necessary for incomplete transactions
Â
Characteristics:
- Requires both undo and redo operations during recovery
- Suitable for real-time systems that demand immediate visibility of data
- More complex but more flexible in high-concurrency environments
Example:
Recovery Strategy:
- Undo all actions of uncommitted transactions
- Redo actions of committed transactions
Summary Table
Feature | Deferred Update | Immediate Update |
---|---|---|
When DB is updated | After commit | Before commit (anytime) |
Log Required? | Yes | Yes |
Undo needed? | No | Yes (for uncommitted) |
Redo needed? | Yes (for committed) | Yes (for committed) |
Recovery Complexity | Simple | More complex |