\documentstyle[]{article}
%\addtolength{\oddsidemargin}{-1in}
%\addtolength{\evensidemargin}{-.5in}
%\addtolength{\textwidth}{1.75in}
%\addtolength{\textheight}{1.75in}
\begin{document}
\noindent
David Golombek\\
6.033 Section 6, David Wetherall\\
Paper \#9: Recovery via Checkpoints\\\\

The System R Database Manager provides a way to do incremental
processing and removal of transactions in a fault-tolerant manner.  It
acheives this goal by keeping a complete log of all transactions that
are processed on the computer.  It then performs occassional
checkpoints, which list all completed and ongoing transactions at that
point in time.  One method of performing these checkpoints is to
perform them during a ``transaction-consistent state''.  This is the
easiest method to implement, but not the best method.

One of the keys to fault-tolerant systems is to have as little an
impact on the normal usage as possible.  It is assumned for most
products that the failure situation is not the normal case, and that
trying to handle it should not slow the normal operations by ``too
much'', a variable term that must be decided on a case by case basis.
Unfortunately, the ``transaction-consistent state'' method of making
checkpoints does exactly this.  In order to perform a checkpoint, this
method must find a time when no other transactions are taking place.
The traditional method for doing this is to pick a time to make the
checkpoint, and prevent new transactions from being registered.  Then
once transactions already in the queue complete, it is safe to perform
the checkpoint.

Unfortunately, it is difficult to determine how long it will take the
transactions in the queue at any point to complete.  If the database
inserts a checkpoint immediately after a long transaction is queued,
then all further transactions may be halted for an unacceptably long
period of time.  The method chosen over the ``transaction-consistent
state'' method is the ``action-consistent state'', which differs in
that the system need not wait for a full transaction to be completed,
but instead only for all RSS actions to be completed.  RSS actions are
much shorter than full transactions, and thus finding a time when none
are being executed is much easier.  Thus the average time to process a
checkpoint is less, and they can be scheduled more frequently.

This leads to a more complicated restoration procedure because only
RSS actions are known to be complete, not full transactions.  With
full transactions, restoring system state after a crash is trivial,
because the exact state of the system is known at the last checkpoint.
However, with action checkpoints, a log of transactions in progress
and their current state must be kept, such that the intermediate state
of the database of the time of the crash can be reconstructed.  

Thus, the ``transaction-consistent state'' method of performing
checkpoints is conceptually simple and easy to implement, but it
impacts too heavily upon the normal mode of operation of the database.
An action-consistent checkpoint method is more difficult to implement,
but speeds up operation greatly.

\end{document}


