Advanced Locking Protocols - Transaction Processing - page 228

In this case page p cannot contain any updates by active transactions, not even by T
itself. If some transaction T 0 had inserted, deleted, or updated some tuple in page p,
then P AGE -LSN .p/ would be greater than the LSN of the begin-transaction log record
of T 0 and hence, if T 0 is still active, greater than C OMMIT -LSN .
It is possible that some transaction T 0 already holds an X lock on a tuple in
page p that will soon be updated, but this update has not yet been done, because
P AGE -LSN .p/ is smaller than the C OMMIT -LSN and hence smaller than the LSN of the
begin-transaction log record of T 0 . Moreover, the update cannot be done before the
thread executing T has released its read latch on page p.
Thus, regardless of whether some T 0 holds such an X lock, no dirty read can
happen, even if T is allowed to read all tuples in p without acquiring any locks on
them. After T has read all of p's tuples, the page is unlatched and unfixed.
This scheme can give significant savings in locking operations if T reads all
tuples from multiple data pages. An S lock must be acquired only on the tuples in
such pages p 0 for which P AGE -LSN .p 0 / is greater than the C OMMIT -LSN . With multi-
granular locking, intention locks (IS, IX, SIX) on lockable units larger than tuples
are acquired as usual.
The C OMMIT -LSN scheme is made even more effective by writing the begin-
transaction log record for a transaction only just before its first update and not
writing begin-transaction or commit log records at all for read-only transactions.

9.7 Recovery and Concurrent Transactions

Usually, it is necessary to apply a locking protocol (or some other concurrency-
control scheme) only during normal transaction processing, when transactions are
generated by multiple concurrent server-process threads. During the redo pass of
restart recovery, no locks need to be acquired, because actions in the redo pass are
always performed in the original order, to repeat a history from the log that had
earlier been accepted. Similarly, it is not necessary to acquire locks for the undo
pass of recovery. Also recall the important principle shared by all locking protocols
that no locks are acquired for undo actions when performing transaction rollbacks.
In Sect. 5.6 we observed that if dirty writes are prevented during normal
transaction processing, active transactions can always be completed to rolled-back
transactions with any interleaving of the undo actions in the undo phase. There will
be no dirty writes in such a completed history nor any other isolation anomalies
that were not already present in the original history. In the undo pass of the ARIES
recovery algorithm, the undo actions are done in reverse chronological order of the
forward-rolling actions, by a single backward scan of the log. This is only one of
the possible orderings (though the most natural).
Normally, no new transactions are allowed to enter the system during recovery.
However, recovery can take a long time, and thus, the data in the database can
be unavailable to the users for a long time. To maintain data availability ,new