The extent of transaction rollback is determined by the outstanding savepoint(s). After executing for a while , the transaction can request the undoing of all the updates performed after the establishment of the most outstanding savepoint. A particular savepoint is no longer outstanding if a rollback has been performed to that save point or to a preceding one. When a savepoint is established , the LSN of the latest log record written by the transaction , called SaveLSN, is remembered in the virtual storage. SaveLSN is set to zero if the savepoint is established at the beginning of the transaction. When the transaction desires to roll-back to a savepoint it supplies the remembered SaveLSN.
The ROLLBACK routine which is used to rollback to a savepoint , takes SaveLSN and TrandID as input. No locks are acquired during rollback , even though a latch is acquired during undo activity on a page. During the rollback , the log records are undone in reverse chronological order and for each log record that is undone , a CLR is written. When a CLR is written , its UndoNxtLSN field is made to contain the PrevLSN value in the log record whose undo caused this CLR to be written. Since CLR's will never be undone, they don't have to contain undo information. Redo-only log records are ignored during rollback. When a non-CLR is encountered , after it is processed , the next record to process is determined by looking up its PrevLSN field. When a CLR is encountered during rollback, the UndoNxtLSN field of that record is looked up to determine the next log record to be processed. Thus the UndoNxtLSN pointer helps us skip over already undone log records. This means that if a nested rollback were to occur , then , because of the UndoNxtLSN in CLRs , during the second rollback none of the log records that were undone during the first rollback would be processed again. This is the main idea used in ARIES.
Being able to describe , via CLRs , the actions performed during undo gives the flexibility of not having to force the undo actions to be the exact inverses of the original actions.
When a transaction rolls back , the locks obtained after the establishment of the savepoint which is the target of the rollback may be released after the partial or total rollback is completed.
Because ARIES never undoes CLRs nor ever undoes a particular non-CLR more than once , because of the chaining of the CLRs using the UndoNxtLSN field, during a rollback, when the transactions very first update to a particular object is undone and a CLR is written for it, the system can release the lock on that object. This makes ARIES to resolve deadlocks using partial rollbacks rather than always resorting to total rollbacks.