UNDO and REDO: The Backbone of Transaction Management
In the world of database recovery, two operations stand as the pillars of transaction integrity: UNDO and REDO.
↩ UNDO Operation
Purpose: Reverse a change, restore original value
Uses old_value: Set variable back to what it was before
When: Transaction aborts or needs to be rolled back
UNDO: seat_id=42, buyer_id: zx198 → ab12
↪ REDO Operation
Purpose: Re-apply a change, set new value
Uses new_value: Set variable to the updated value
When: Transaction commits or needs to be re-applied after crash
REDO: seat_id=42, buyer_id: ab12 → zx198
UNDO/REDO in Action
Consider the mechanics of a ticket resale transaction:
What T56's log entries reveal:
-
Every change logs both
oldandnewvalues. -
UNDO leverages old values to roll back changes.
-
REDO uses new values to reapply changes.
-
The COMMIT or ABORT record is the final arbiter of the transaction's fate.
The COMMIT vs ABORT Decision
COMMIT Path
Outcome: Changes are cemented into the database.
-
REDO operations ensure these changes are durable.
-
Other transactions see the updated data.
ABORT Path
Outcome: Changes are wiped clean.
-
UNDO operations restore the database to its original state.
-
It's as if the transaction never happened.