A few final citations (for atomic heaps), some reference clean up, latex badness < 2400 now. :)
Still need to check figure captions, citations, end notes.
This commit is contained in:
parent
c0773fc425
commit
73f67a2a62
2 changed files with 62 additions and 53 deletions
|
@ -14,7 +14,7 @@
|
|||
|
||||
@Book{camelot,
|
||||
ALTauthor = {},
|
||||
editor = {Jeffrey L Eppinger and Lily B Mummert and Alfred Z Spector},
|
||||
editor = {Jeffrey L. Eppinger and Lily B. Mummert and Alfred Z. Spector},
|
||||
title = {Camelot and Avalon, A Distributed Transaction Facility},
|
||||
publisher = {Morgan Kaufmann},
|
||||
year = {1991},
|
||||
|
@ -45,19 +45,15 @@
|
|||
|
||||
|
||||
|
||||
@Book{dtp,
|
||||
author = {{The Open Group}},
|
||||
ALTeditor = {},
|
||||
@Manual{dtp,
|
||||
title = {Distributed Transaction Processing: Reference Model},
|
||||
publisher = {},
|
||||
year = {1996},
|
||||
OPTkey = {},
|
||||
OPTvolume = {},
|
||||
OPTnumber = {},
|
||||
OPTseries = {},
|
||||
OPTauthor = {},
|
||||
organization = {{The Open Group}},
|
||||
OPTaddress = {},
|
||||
OPTedition = {},
|
||||
OPTmonth = {},
|
||||
year = {1996},
|
||||
OPTnote = {},
|
||||
OPTannote = {}
|
||||
}
|
||||
|
@ -194,7 +190,7 @@
|
|||
}
|
||||
|
||||
@Article{excel,
|
||||
author = {B Zeeberg and J Riss and D Kane D and K Bussey and E Uchio and W Linehan and J Barret and J Weinstein},
|
||||
author = {Barry R Zeeberg and Joseph Riss and David W Kane and Kimberly J Bussey and Edward Uchio and W. Marston Linehann and J. Carl Barrett and John N Weinstein},
|
||||
title = {Mistaken identifiers: Gene name errors can be introduced inadvertently when using {E}xcel in bioinformatics},
|
||||
journal = {BMC Bioinformatics},
|
||||
year = {2004},
|
||||
|
@ -272,7 +268,7 @@
|
|||
@Misc{hibernate,
|
||||
key = {hibernate},
|
||||
OPTauthor = {},
|
||||
title = {Hibernate: Relational Persistence for {J}ava and {.NET}},
|
||||
title = {Hibernate},
|
||||
OPThowpublished = {},
|
||||
OPTmonth = {},
|
||||
OPTyear = {},
|
||||
|
@ -383,7 +379,7 @@
|
|||
}
|
||||
|
||||
@Article{starburst,
|
||||
author = {Guy M. Lohman and Bruce Lindsay and Hamid Pirahesh and K. Bernhard Schiefer},
|
||||
author = {Guy Lohman and Bruce Lindsay and Hamid Pirahesh and K. Bernhard Schiefer},
|
||||
title = {Extensions to {S}tarburst: Objects, types, functions, and rules},
|
||||
journal = {Communications of the ACM},
|
||||
year = {1991},
|
||||
|
@ -484,7 +480,7 @@
|
|||
}
|
||||
|
||||
@InProceedings{aries,
|
||||
author = { C. Mohan and D. Haderle and B. Lindsay and H. Pirahesh and P Schwarz },
|
||||
author = { C. Mohan and D. Haderle and B. Lindsay and H. Pirahesh and Peter M. Schwarz },
|
||||
title = {{ARIES}, A Transaction Recovery Method Supporting Fine-Granularity Locking and Partial Rollbacks Using Write-Ahead Logging},
|
||||
OPTcrossref = {},
|
||||
OPTkey = {},
|
||||
|
@ -503,6 +499,21 @@
|
|||
OPTannote = {}
|
||||
}
|
||||
|
||||
@inproceedings{stableHeap,
|
||||
author = {Elliot K. Kolodner and
|
||||
William E. Weihl},
|
||||
title = {Atomic Incremental Garbage Collection and Recovery for a
|
||||
Large Stable Heap.},
|
||||
booktitle = {SIGMOD},
|
||||
year = {1993},
|
||||
pages = {177-186},
|
||||
ee = {http://doi.acm.org/10.1145/170035.170068, db/conf/sigmod/KolodnerW93.html},
|
||||
OPTcrossref = {DBLP:conf/sigmod/93},
|
||||
bibsource = {DBLP, http://dblp.uni-trier.de}
|
||||
}
|
||||
|
||||
|
||||
|
||||
@Book{ariesIM,
|
||||
author = {C Mohan and F Levine},
|
||||
ALTeditor = {},
|
||||
|
@ -543,7 +554,7 @@
|
|||
OPTnumber = {},
|
||||
OPTseries = {},
|
||||
OPTaddress = {},
|
||||
month = {Janurary},
|
||||
month = {January},
|
||||
OPTorganization = {},
|
||||
OPTpublisher = {},
|
||||
OPTnote = {},
|
||||
|
@ -698,7 +709,7 @@
|
|||
OPTeditor = {Peter Buneman and
|
||||
Sushil Jajodia},
|
||||
title = {The {OO7} Benchmark},
|
||||
booktitle = {SIGMOD International Conference on Management of Data},
|
||||
booktitle = {SIGMOD},
|
||||
OPTpublisher = {ACM Press},
|
||||
year = {1993},
|
||||
pages = {12-21},
|
||||
|
|
|
@ -36,8 +36,8 @@
|
|||
\newcommand{\eab}[1]{\textcolor{red}{\bf EAB: #1}}
|
||||
\newcommand{\rcs}[1]{\textcolor{green}{\bf RCS: #1}}
|
||||
|
||||
%\newcommand{\eab}[1]{}
|
||||
%\newcommand{\rcs}[1]{}
|
||||
%\renewcommand{\eab}[1]{}
|
||||
%\renewcommand{\rcs}[1]{}
|
||||
|
||||
|
||||
\newcommand{\eat}[1]{}
|
||||
|
@ -63,7 +63,7 @@
|
|||
|
||||
\maketitle
|
||||
|
||||
\vspace*{-.25in}
|
||||
%\vspace*{-.25in} % This was only moving the first column up. Putting it in the \author block moves the title down, and putting it before \maketitle adds a blank page...
|
||||
|
||||
% Use the following at camera-ready time to suppress page numbers.
|
||||
% Comment it out when you first submit the paper for review.
|
||||
|
@ -71,7 +71,7 @@
|
|||
|
||||
%\abstract
|
||||
%\subsection*{Abstract}
|
||||
\rcs{Spell check, look at end notes and figure captions. Spell check / cannonicalize bibtex. Embed graph fonts. Make sure $a < b$ when we have cites like [a, b]. Check nocite *}
|
||||
%\rcs{Done, except graph fonts, but double check. Spell check, look at end notes and figure captions. Spell check / canonicalize bib TeX. Embed graph fonts. Make sure $a < b$ when we have cites like [a, b]. Check no cite *}
|
||||
|
||||
{\em An increasing range of applications requires robust support for atomic, durable and concurrent
|
||||
transactions. Databases provide the default solution, but force
|
||||
|
@ -297,7 +297,7 @@ Section~\ref{sec:related-work} covers these in more detail.
|
|||
In some sense, our hypothesis is trivially true in that there exists a
|
||||
bottom-up framework called the ``operating system'' that can implement
|
||||
all of the models. A famous database paper argues that it does so
|
||||
poorly (Stonebraker 1981~\cite{Stonebraker81}). Our task is really to
|
||||
poorly~\cite{Stonebraker81}. Our task is really to
|
||||
simplify the implementation of transactional systems through more
|
||||
powerful primitives that enable concurrent transactions with a variety
|
||||
of performance/robustness tradeoffs.
|
||||
|
@ -627,7 +627,7 @@ order to implement a ``typical'' operation, the operation's
|
|||
implementation must obey a few more invariants:
|
||||
\begin{itemize}
|
||||
\item Pages should only be updated inside physical redo/undo operation implementations.
|
||||
\item Logical operation implementations may invoke other operations
|
||||
\item Logical operations may invoke other operations
|
||||
via {\tt Tupdate()}. Recovery does not support logical redo,
|
||||
and physical operation implementations may not invoke {\tt
|
||||
Tupdate()}.
|
||||
|
@ -644,7 +644,8 @@ implementation must obey a few more invariants:
|
|||
Although these restrictions are not trivial, they are not a problem in
|
||||
practice. Most read-modify-write actions can be implemented as
|
||||
user-defined operations, including common DBMS optimizations such as
|
||||
increment operations. The power of \yad is that by following these
|
||||
increment operations, and many optimizations based on
|
||||
ARIES~\cite{stableHeap, ariesIM}. The power of \yad is that by following these
|
||||
local restrictions, operations meet the global
|
||||
invariants required by correct, concurrent transactions.
|
||||
|
||||
|
@ -671,15 +672,15 @@ way that does not deadlock. This allows higher-level code to treat
|
|||
This section describes \yads latching protocols and describes two custom lock
|
||||
managers that \yads allocation routines use. Applications that want
|
||||
conventional transactional isolation (serializability) can make
|
||||
use of a lock manager. Alternatively, applications may follow
|
||||
use of a lock manager or optimistic concurrency control~\cite{optimisticConcurrencyPerformance, optimisticConcurrencyControl}. Alternatively, applications may follow
|
||||
the example of \yads default data structures, and implement
|
||||
deadlock prevention, or other custom lock management
|
||||
schemes~\cite{hybridAtomicity, optimisticConcurrencyPerformance, optimisticConcurrencyControl}.
|
||||
schemes.
|
||||
|
||||
Note that locking schemes may be
|
||||
layered as long as no legal sequence of calls to the lower level
|
||||
results in deadlock, or the higher level is prepared to handle
|
||||
deadlocks reported by the lower levels~\cite{someOtherLayeringPaper}.
|
||||
deadlocks reported by the lower levels.
|
||||
|
||||
When \yad allocates a
|
||||
record, it first calls a region allocator, which allocates contiguous
|
||||
|
@ -710,7 +711,7 @@ transparent to higher layers. General-purpose database lock managers
|
|||
provide none of these features, supporting the idea that
|
||||
special-purpose lock managers are a useful abstraction. Locking
|
||||
schemes that interact well with object oriented programming
|
||||
schemes~\cite{sharedAbstractTypes,billOOlockingProtocols} and exception
|
||||
schemes~\cite{sharedAbstractTypes} and exception
|
||||
handling~\cite{omtt} extend these ideas to larger systems.
|
||||
|
||||
Although custom locking is important for flexibility, it is largely
|
||||
|
@ -848,7 +849,7 @@ entering metadata in the primary log.
|
|||
|
||||
\subsection{Concurrent RVM}
|
||||
|
||||
Our LSN-free pages are similar to the recovery scheme used by
|
||||
LSN-free pages are similar to the recovery scheme used by
|
||||
recoverable virtual memory (RVM) and Camelot~\cite{camelot}. RVM
|
||||
used purely physical logging and LSN-free pages so that it
|
||||
could use {\tt mmap} to map portions of the page file into application
|
||||
|
@ -998,9 +999,9 @@ All benchmarks were run on an Intel Xeon 2.8 GHz processor with 1GB of RAM and a
|
|||
types.} All results correspond to the mean of multiple runs with a
|
||||
95\% confidence interval with a half-width of 5\%.
|
||||
|
||||
We used Berkeley DB 4.2.52
|
||||
Our experiments use Berkeley DB 4.2.52
|
||||
%as it existed in Debian Linux's testing branch during March of 2005,
|
||||
with the flags DB\_TXN\_SYNC (sync log on commit), and
|
||||
with the flags DB\_TXN\_SYNC (force log to disk on commit), and
|
||||
DB\_THREAD (thread safety) enabled. We
|
||||
increased Berkeley DB's buffer cache and log buffer sizes to match
|
||||
\yads default sizes. If
|
||||
|
@ -1163,13 +1164,15 @@ on top of \yad.
|
|||
%model would allow us to choose the representation and transactional
|
||||
%semantics that make the most sense for the system at hand.
|
||||
%
|
||||
The first object persistence mechanism, pobj, provides transactional updates to objects in
|
||||
Titanium, a Java variant. It transparently loads and persists
|
||||
entire graphs of objects, but will not be discussed in further detail.
|
||||
The second variant was built on top of a C++ object
|
||||
persistence library, \oasys. \oasys uses plug-in storage
|
||||
modules that implement persistent storage, and includes plugins
|
||||
for Berkeley DB and MySQL.
|
||||
The first object persistence mechanism, pobj, provides transactional
|
||||
updates to objects in Titanium, a Java variant. It transparently
|
||||
loads and persists entire graphs of objects, but will not be discussed
|
||||
in further detail. The second variant was built on top of a C++
|
||||
object persistence library, \oasys. \oasys uses plug-in storage
|
||||
modules that implement persistent storage, and includes plugins for
|
||||
Berkeley DB and MySQL. Like C++ objects, \oasys objects are
|
||||
explicitly freed. However, \yad could also support
|
||||
concurrent and incremental atomic garbage collection~\cite{stableHeap}.
|
||||
|
||||
This section describes how the \yad plugin supports optimizations that reduce the
|
||||
amount of data written to log and halve the amount of RAM required.
|
||||
|
@ -1184,7 +1187,7 @@ application objects to become stale. This is safe since the system is
|
|||
always able to reconstruct the appropriate page entry from the live
|
||||
copy of the object. This reduces the number of times the
|
||||
plugin must update serialized objects in the buffer manager, and
|
||||
allows us to decrease drastically the amount of memory used by the
|
||||
allows us to nearly eliminate the memory used by the
|
||||
buffer manager.
|
||||
|
||||
We implemented the \yad buffer pool optimization by adding two new
|
||||
|
@ -1308,10 +1311,10 @@ independently, improving locality and allowing requests to be merged.}
|
|||
clip,
|
||||
width=1\columnwidth]{figs/trans-closure-hotset.pdf}}
|
||||
\vspace{-12pt}
|
||||
\caption{\label{fig:hotGraph} Hot-set based graph traversal for random graphs with out-degrees of 3 and 9. Here
|
||||
we see that the multiplexer helps when the graph has poor locality.
|
||||
In the cases where depth first search performs well, the
|
||||
reordering is inexpensive.}
|
||||
\caption{\label{fig:hotGraph} Hot-set based graph traversal for random
|
||||
graphs with out-degrees of 3 and 9. Here we see that the multiplexer
|
||||
has relatively low overhead, and improves performance when the graph
|
||||
has poor locality.}
|
||||
\vspace{-12pt}
|
||||
\end{figure}
|
||||
|
||||
|
@ -1331,7 +1334,7 @@ techniques and relational algebra operators could be used to
|
|||
non-transactional memory.
|
||||
|
||||
To experiment with the potential of such optimizations, we implemented
|
||||
a single node log-reordering scheme that increases request locality
|
||||
a single-node log-reordering scheme that increases request locality
|
||||
during a graph traversal. The graph traversal produces a sequence of
|
||||
read requests that are partitioned according to their physical
|
||||
location in the page file. Partition sizes are chosen to fit inside
|
||||
|
@ -1355,8 +1358,8 @@ The second experiment measures the effect of graph locality
|
|||
(Figure~\ref{fig:hotGraph}). Each node has a distinct hot set that
|
||||
includes the 10\% of the nodes that are closest to it in ring order.
|
||||
The remaining nodes are in the cold set. We do not use ring edges for
|
||||
this test, so the graphs might not be connected. We use the same set
|
||||
of graphs for both systems.
|
||||
this test, so the graphs might not be connected. We use the same
|
||||
graphs for both systems.
|
||||
|
||||
When the graph has good locality, a normal depth-first search
|
||||
traversal and the prioritized traversal both perform well. As
|
||||
|
@ -1577,9 +1580,9 @@ than QuickSilver, but is not designed for legacy applications.
|
|||
\subsection{Data Structure Frameworks}
|
||||
|
||||
As mentioned in Section~\ref{sec:systems}, Berkeley DB is a system
|
||||
quite similar to \yad, and provides raw access to
|
||||
transactional data structures for application
|
||||
programmers~\cite{libtp}. \eab{summary?}
|
||||
quite similar to \yad, and gives application programmers raw access to
|
||||
transactional data structures such as a single-node B-Tree and hash
|
||||
table~\cite{libtp}.
|
||||
|
||||
Cluster hash tables provide a scalable, replicated hash table
|
||||
implementation by partitioning the table's buckets across multiple
|
||||
|
@ -1629,10 +1632,6 @@ hints~\cite{cricket}, pointer values and write order~\cite{starburst},
|
|||
data type~\cite{orion}, or access
|
||||
patterns~\cite{storageReorganization}.
|
||||
|
||||
%Other work makes use of the caller's stack to infer
|
||||
%information about memory management.~\cite{xxx} \rcs{Eric, do you have
|
||||
% a reference for this?}
|
||||
|
||||
We are interested in allowing applications to store records in
|
||||
the transaction log. Assuming log fragmentation is kept to a
|
||||
minimum, this is particularly attractive on a single disk system. We
|
||||
|
@ -1659,7 +1658,7 @@ this trend to continue as development progresses.
|
|||
|
||||
A resource manager is a common pattern in system software design, and
|
||||
manages dependencies and ordering constraints between sets of
|
||||
components~\cite{resourceManager}. Over time, we hope to shrink \yads core to the point
|
||||
components. Over time, we hope to shrink \yads core to the point
|
||||
where it is simply a resource manager that coordinates interchangeable
|
||||
implementations of the other components.
|
||||
|
||||
|
@ -1710,7 +1709,6 @@ Additional information, and \yads source code is available at:
|
|||
|
||||
{\footnotesize \bibliographystyle{acm}
|
||||
|
||||
\rcs{What's ``SIGMOD International Conference on Management of Data'' vs ``SIGMOD Record''?}
|
||||
%\nocite{*}
|
||||
\bibliography{LLADD}}
|
||||
|
||||
|
|
Loading…
Reference in a new issue