\documentclass[11pt]{article}
\usepackage{fullpage,amsmath,amsthm,amsfonts,amssymb,qtree}

\begin{document}

\title{Optimizing Distributed Read-Only Transactions Using~Multiversion~Concurrency}
\author{Dan R. K. Ports \hspace{1em}
  Austin T. Clements \hspace{1em}
  Irene Y. Zhang\\
 \normalsize{\texttt{\{drkp,amdragon,iyzhang\}@mit.edu}}}
\date{November 20, 2007}

\maketitle

\section{Architecture}
\small{
\Tree [.{Block Manager} [.{Node Manager} Client Client $\ldots$ ]
[.{Node Manager} Client $\ldots$ ] $\ldots$ ]}

\begin{itemize}
\item \textbf{Block manager} is the centralized block store. It
  assigns timestamps to transactions and guarantees that they're
  serializable. For simplicity, we'll assume for now that there's only
  one, though everything will also work (with a bit more complexity)
  using multiple block managers.

\item \textbf{Node managers} are the processes that run on each node,
  communicate with the block manager, and maintain the local cache.
\end{itemize}

Each node manager keeps a cache of items it has requested from the
block manager, and does not discard cached data when it becomes
stale. (For simplicity, we'll suppose that all old versions are kept
around forever, but obviously this isn't true.) For each block, it
keeps track of the validity interval for each version: when it was
created and when it was superseded. For current versions, the validity
interval can be infinite. The server keeps track of which blocks the
node managers have in their cache, and sends \emph{invalidation}
messages when they are modified, so the node managers can update their
validity intervals and abort any conflicting transactions
immediately.

\section{Properties}

\newtheorem{property}{Property}
\begin{property}[Global Serializability]
  There exists a global serial ordering of all transactions such that
  the results of all transactions is consistent with this ordering.
\end{property}

\begin{property}[Local Causality]
  A transaction will see the effects of all transactions on the local
  node that committed before it started.
\end{property}

\begin{property}[Freshness]
  A read-only transaction sees a consistent state of the database at a
  time no earlier than $\epsilon$ before the time it began, where
  $\epsilon$ is a property of the transaction.
\end{property}

\begin{property}[Conflict-freeness]
  Read-only transactions are never aborted, and can be executed
  without blocking for another transaction.
\end{property}

\section{Protocol}

Read-write transactions are handled using a standard OCC approach:
read requests access the current version of the block, either from
cache or fetched from the block manager, and write operations are
performed on a transaction-local copy. Upon commit, the modified pages
are sent to the block manager along with the read and write sets. The
block manager uses the read and write sets (in the standard way) to
verify that the transaction doesn't conflict with any previously
committed transaction. If validation succeeds, the block manager
assigns the transaction the current timestamp, installs its modified
blocks, and sends appropriate invalidations.

Read-only transactions are assigned a timestamp when they begin. This
timestamp must satisfy the $\epsilon$-freshness property, and it must
be less than the timestamp of the last invalidation message received
at the server to ensure that it does not conflict with any later
write. For example, it can be assigned the timestamp just after the
last committed write in the cache. Read operations access versions of
blocks that were valid at this timestamp, fetching them from the
server if necessary.

\end{document}