Topic of discussion : Difficulties introduced by rollbacks in tracking their progress.
CLR technique solves most of such difficulties.
A transaction totally or partial rolls back its actions for any number of reasons. Supporting partial rollback is the important requirement for present day transaction system. System R : DB changes performed after the last checkpoint are not visible in the DB during restart. Hence for System R rollback state of a transaction at the time of a system failure is not important. But System R has to do some special handling to avoid the need for multiple passes over log during the redo pass.
Figure 8: Simple view of recovery processing in System R
Figure 9: partial rollback handling in System R
NOTE : System R neither writes CLR, nor a separate log to say that a partial rollback took place.
Partial rollback of 3 started with undo of 3 ended with undo of 2.
During restart, from the last checkpoint log record 2 needs to be done.
From fig 8, partial rollback had caused the undo of 6,7,8. To ensure that the rolled back records are not redone during redo pass, log is patched by putting a forward pointer during the analysis pass in log record 5 to make it to point to 9.
In System R, undo pass has to precede redo pass.
Since System R does not write CLR, hence the processing for a given page as well as across different pages during restart may be quite different.
Not logging index changes further contributes to this.
This causes space management problems.
Not logging CLR also prevents logging of redo information from being done physically.
Allowing the logging of undo information logically will support high concurrency, ARIES supports these.
WAL based systems log actions, performed during rollbacks using CLR.
CLR consequence : If a transaction were to be rolled back, then some of its original actions are undone more than once and the compensating actions are also undone, more than once.