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

update oasys experiment section

Browse source
This commit is contained in:
Mike Demmer 2005-03-25 20:58:51 +00:00
parent 73c36ae994
commit 5b0905ba8a
1 changed files with 15 additions and 11 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

26
doc/paper2/LLADD.tex
View file

@ -1845,20 +1845,24 @@ when the object is flushed from cache.
\yad provides a several options to handle undo records in the context \yad provides a several options to handle undo records in the context
of object serialization. The first is to use a single transaction for of object serialization. The first is to use a single transaction for
each object modification, avoiding the cost of generating or logging each object modification, avoiding the cost of generating or logging
any undo records. No other transactional system that we know of allows any undo records. The second option is to assume that the
this type of optimization \eab{sure?}. The second option is to assume that the application will provide a custom undo for the delta,
application will provide a custom undo for the delta, which requires a log entry for each update, but still avoids the need to read or update the page which requires a log entry for each update,
but still avoids the need to read or update the page
file. file.
The third option is to relax the atomicity requirements for a set of The third option is to relax the atomicity requirements for a set of
object updates, and again avoid generating any undo records. This object updates, and again avoid generating any undo records. This
assumes that the application cannot abort individual updates, and is willing to assumes that the application cannot abort individual updates,
accept that a prefix of the logged updates will be applied to the page and is willing to
file after recovery. These ``transactions'' would still be durable, as accept that some prefix of logged but uncommitted updates may
commit() could force the log to disk. For the benchmarks below, we be applied to the page
opted for this approach, as it is the most aggressive and would be the file after recovery. These ``transactions'' would still be durable
most difficult to implement in another storage system. after commit(), as it would force the log to disk.
\eab{dont' get why we get a prefix if we use commit} For the benchmarks below, we
use this approach, as it is the most aggressive and is
not supported by any other general purpose transactional
storage system that we know of.
\subsection{Recovery and Log Truncation} \subsection{Recovery and Log Truncation}
\label{version-pages} \label{version-pages}
@ -1896,7 +1900,7 @@ by the page LSN so that unrelated updates remain independent.
Recovery work essentially the same as before, except that we need to Recovery work essentially the same as before, except that we need to
use RSNs to calculate the earliest allowed point for log truncation use RSNs to calculate the earliest allowed point for log truncation
(so as to not lose an older record update). In the implementation, we (so as to not lose an older record update). In the implementation, we
also peridically flush the object cache to move the truncation point also periodically flush the object cache to move the truncation point
forward, but this is not required. forward, but this is not required.
%% We have two solutions to this problem. One solution is to %% We have two solutions to this problem. One solution is to