Techniques based on deferred update and immediate update

Definition

Deferred update is a recovery technique in which database changes made by a transaction are not written to the database immediately; instead, they are stored in a log or temporary area and applied to the database only after the transaction commits.

Immediate update is a recovery technique in which database changes made by a transaction may be written to the database before the transaction commits, meaning the database can reflect uncommitted changes temporarily, and recovery is needed to undo or redo operations after failure.

Main Content

1. Deferred Update Technique

Meaning and principle

• : In deferred update, the database is not changed permanently until the transaction successfully completes. All updates are first recorded in the log and often kept in memory or a private workspace. Only after the system confirms that the transaction has committed are the changes propagated to the actual database.

Recovery implication

• : Since uncommitted updates never reach the database, recovery after a crash is simpler. If a failure occurs before commit, there is usually no need to undo the transaction’s actions because the database was never modified by them. Recovery mainly involves redoing committed transactions that were logged but not fully applied.

Example:
Suppose a transaction transfers ₹500 from Account A to Account B:

• Debit A by ₹500
• Credit B by ₹500

In deferred update, these changes are written to the log first. If the system crashes before commit, A and B remain unchanged in the database. If the transaction commits but the crash happens before the database is updated, recovery will reapply the logged changes.

2. Immediate Update Technique

Meaning and principle

• : In immediate update, modifications are allowed to reach the database as soon as they are made, even before commit. This means the database can contain changes from transactions that may later abort.

Recovery implication

• : Because uncommitted changes may already be present in the database, recovery becomes more complex. After a crash, the system may need to redo committed transactions and undo uncommitted transactions to restore consistency.

Example:
Using the same account transfer:

• The system may reduce Account A immediately.
• It may later increase Account B.
• If a crash happens after A is debited but before B is credited, the database may temporarily be inconsistent.
• Recovery must identify whether the transaction committed; if not, the debit to A must be undone.

3. Comparison of Deferred Update and Immediate Update

Timing of database modification

• Deferred update: Changes are applied only after commit.
• Immediate update: Changes can be applied before commit.

Recovery actions

• Deferred update: Usually requires redo only for committed transactions.
• Immediate update: Requires both undo and redo.

Complexity and performance

• Deferred update: Easier recovery but may delay visibility of changes.
• Immediate update: Faster availability of updated data but more complex recovery control.

The difference can be understood by this flow:

Deferred Update:
Transaction actions -> Log records -> Commit -> Apply to database

Immediate Update:
Transaction actions -> Update database -> Log records maintained -> Commit/Abort -> Recovery if needed

Working / Process

1. Transaction starts and generates update operations

A transaction reads and modifies data items. In both techniques, the system records these actions in a log to support recovery. The log typically includes the transaction ID, the item changed, the old value, and the new value.

2. System follows the chosen update policy

• In deferred update, the actual database remains unchanged until commit. The new values are stored in a temporary buffer or log.
• In immediate update, the changes may be written to the database right away, even if the transaction is still active.

3. Commit, failure, and recovery handling

• If the transaction commits successfully:
  • Deferred update applies the logged changes to the database.
  • Immediate update simply confirms the changes and records the commit.
• If a failure occurs:
  • Deferred update redoes committed transactions only.
  • Immediate update undoes incomplete transactions and redoes committed ones if necessary.

Time ---->

Deferred Update:
Begin -> Log updates -> More processing -> Commit -> Write to database

Immediate Update:
Begin -> Write some/all updates -> More processing -> Commit/Abort

Advantages / Applications

Deferred update advantages

• Recovery is simpler because uncommitted changes never pollute the database.
• No undo is usually required for aborted transactions.
• Suitable for systems that prioritize correctness and simpler restart procedures.

Immediate update advantages

• Data becomes available sooner, which improves responsiveness.
• Better for high-performance systems where waiting until commit would be too slow.
• Common in real-world DBMS implementations because it supports flexible buffering and concurrency.

Applications in database systems

• Banking systems, reservation systems, inventory management, and online payment systems use these techniques to ensure atomicity and durability.
• Immediate update is widely used in systems requiring frequent updates and high concurrency.
• Deferred update is useful in environments where recovery simplicity is more important than instant visibility.

Summary

• Deferred update applies changes only after commit.
• Immediate update may apply changes before commit.
• Deferred update usually needs redo recovery, while immediate update needs undo and redo.
• Important terms to remember: transaction, log, commit, abort, redo, undo, recovery