greg/stasis-aries-wal
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

edits

Browse source
This commit is contained in:
Eric Brewer 2004-10-23 02:23:50 +00:00
parent bc6b6756da
commit d40ba83388
2 changed files with 14 additions and 15 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

BIN
doc/paper/LLADD-Freenix.pdf
View file

Binary file not shown.

29
doc/paper/LLADD-Freenix.tex
View file

@ -310,7 +310,7 @@ all information necessary for undo and redo.
An important concept in ARIES is the ``log sequence number'' or LSN. An important concept in ARIES is the ``log sequence number'' or LSN.
An LSN is essentially a virtual timestamp that goes on every page; it An LSN is essentially a virtual timestamp that goes on every page; it
tells you the last log entry that is reflect on the page, which marks the last log entry that is reflected on the page, which
implies that all previous log entries are also reflected. Given the implies that all previous log entries are also reflected. Given the
LSN, you can tell where to start playing back the log to bring a page LSN, you can tell where to start playing back the log to bring a page
up to date. The LSN goes on the page so that it is always written to up to date. The LSN goes on the page so that it is always written to
@ -325,7 +325,7 @@ as we allow multiple transactions to run concurrently on the same page
always} contains some uncommitted data and thus could never be written always} contains some uncommitted data and thus could never be written
back to disk. To handle stolen pages, we log UNDO records that back to disk. To handle stolen pages, we log UNDO records that
we can use to undo the uncommitted changes in case we crash. LLADD we can use to undo the uncommitted changes in case we crash. LLADD
ensures that the UNDO record is be durable in the log before the ensures that the UNDO record is durable in the log before the
page is written back to disk, and that the page LSN reflects this log entry. page is written back to disk, and that the page LSN reflects this log entry.
Similarly, we do not force pages out to disk every time a transaction Similarly, we do not force pages out to disk every time a transaction
@ -366,19 +366,18 @@ processing.
\subsubsection{The buffer manager} \subsubsection{The buffer manager}
LLADD manages memory on behalf of the application and prevents pages LLADD manages memory on behalf of the application and prevents pages
from being stolen prematurely. Although LLADD uses the STEAL policy and from being stolen prematurely. Although LLADD uses the STEAL policy
may write buffer pages to disk before transaction commit, it still and may write buffer pages to disk before transaction commit, it still
must make sure that the undo log entries have been forced must make sure that the UNDO log entries have been forced to disk
to disk before the page is written to disk. Therefore, operations before the page is written to disk. Therefore, operations must inform
must inform the buffer manager when they write to a page, and update the buffer manager when they write to a page, and update the LSN of
the LSN of the page. This is handled automatically the page. This is handled automatically by the write methods that LLADD
by many of the write methods provided to operation implementors (such provides to operation implementors (such as writeRecord()). However,
as writeRecord()), but the low-level page manipulation calls (which it is also possible to create your own low-level page manipulation
allow byte-level page manipulation) leave it to their callers to update routines, in which case these routines must follow the protocol.
the page metadata appropriately.
\subsubsection{Log entries and forward operation (the Tupdate() function)\label{sub:Tupdate}} \subsubsection{Log entries and forward operation\\ (the Tupdate() function)\label{sub:Tupdate}}
In order to handle crashes correctly, and in order to the undo the In order to handle crashes correctly, and in order to the undo the
effects of aborted transactions, LLADD provides operation implementors effects of aborted transactions, LLADD provides operation implementors
@ -386,8 +385,8 @@ with a mechanism to log undo and redo information for their actions.
This takes the form of the log entry interface, which works as follows. This takes the form of the log entry interface, which works as follows.
Operations consist of a wrapper function that performs some pre-calculations Operations consist of a wrapper function that performs some pre-calculations
and perhaps acquires latches. The wrapper function then passes a log and perhaps acquires latches. The wrapper function then passes a log
entry to LLADD. LLADD passes this entry to the logger, and then processes entry to LLADD. LLADD passes this entry to the logger, {\em and then processes
it as though it were redoing the action during recovery, calling a function it as though it were redoing the action during recovery}, calling a function
that the operation implementor registered with that the operation implementor registered with
LLADD. When the function returns, control is passed back to the wrapper LLADD. When the function returns, control is passed back to the wrapper
function, which performs any post processing (such as generating return function, which performs any post processing (such as generating return