%  6.826 (POCS Seminar) style file for scribe notes.
%
% You should save this file as pocs-header.sty
%
% Your main LaTeX file should look like this:
%
%        \documentstyle[12pt,pocs-header]{article}
%        \Scribes{*First1 Last1* and *First2 Last2*}
%	  or \Scribe{*First Last*}
%        \Lecturer{*First Last*}
%	  or \Lecturers{*First1 Last1* and *First2 Last2*}	
%        \LectureNumber{*N*}
%        \LectureDate{*Date*}
%        \begin{document}
%        \MakeScribeTop
%
%        \section{*Section Name*}
%
%        *stuff*
%
%        \section{*Section Name*}
%
%        *stuff*
%
%        etc.
%
%       \end{document}
%
\oddsidemargin 0in
\evensidemargin 0in
\marginparwidth 40pt
\marginparsep 10pt
\topmargin 0pt
\headsep 0in
\headheight 0in
\textheight 8.5in
\textwidth 6.5in
\brokenpenalty=10000

\def\ScribeStr{??}
\def\LecStr{??}
\def\LecNum{??}
\def\LecDate{??}
\newcommand{\Scribe}[1]{\def\ScribeStr{Scribe: #1}}
\newcommand{\Scribes}[1]{\def\ScribeStr{Scribes: #1}}
\newcommand{\Lecturer}[1]{\def\LecStr{Lecturer: #1}}
\newcommand{\Lecturers}[1]{\def\LecStr{Lecturers: #1}}
\newcommand{\LectureNumber}[1]{\def\LecNum{#1}}
\newcommand{\LectureDate}[1]{\def\LecDate{#1}}

\newdimen\headerwidth

\newcommand{\MakeScribeTop}{
\noindent
\begin{center}
  \framebox{
    \vbox{
      \headerwidth=\textwidth
      \advance\headerwidth by -0.22in
      \hbox to \headerwidth {{\bf 6.826 Principles of Computer Systems \hfill
                              Fall Semester, 1990} }
      \vspace{4mm}
      \hbox to \headerwidth {{\Large \hfill Lecture \LecNum: \LecDate \hfill}}
      \vspace{2mm}
      \hbox to \headerwidth {{\it \LecStr \hfill \ScribeStr}}
      }
    }
\end{center}
\vspace*{4mm}
}

\documentstyle[12pt,pocs-header]{article}
\Scribes{Ellen Spertus and Jory Tsai}
\Lecturers{Bill Weihl and Butler Lampson}
\LectureNumber{14}
\LectureDate{October 31, 1990}
\begin{document}
\MakeScribeTop

\section{Methods of Serializing Transactions}

Last time, we discussed two-phase locking (2-PL), which serializes
commit transactions in lockpoint order, i.e. simulates that each 
takes place atomically at the time of its lock.  
Today other mechanisms were discussed:

\begin{enumerate}
\item Timestamps --- Timestamps involve keeping different versions of
data, specifically a ``base'' version which has the state before any
uncommitted transactions began and one or more tentative versions of
the data.  Each version is tagged with the latest timestamp of any
transaction that reads it and the latest timestamp of any transaction
that writes it.  This gives us the information we need to decide when a
read or write is legal and when a transaction needs to be aborted.

For example, $T_2$ is allowed to read a value that $T_1$, which has an
earlier timestamp, has written:
$$
\underbrace{\ \ \ \ \ \ Write \ \ \ \ \ \ }_{T_1} 
\longrightarrow
\underbrace{\ \ \ \ \ \ Read \ \ \ \ \ \ }_{T_2} 
$$
However, if $T_3$, with a timestamp after $T_1$'s and before $T_2$'s,
tried to write the same value, an error would occur, which would
probably lead to an aborted transaction:
$$
\underbrace{\ \ \ \ \ \ Write \ \ \ \ \ \ }_{T_1} 
\longrightarrow
\uparrow_{T_3}
\underbrace{\ \ \ \ \ \ Read \ \ \ \ \ \ }_{T_2} 
$$

In general, an object can be thought of as a sequence of versions.  In
order to read the value of an object, the system goes back to the last
transaction that wrote it.  If that write is not in a transaction that
has committed (and is not earlier in the reading transaction), the
request must either abort or wait for it to commit.  If a subsequent
write occurred in a transaction whose timestamp was between that of
the writer and the reader, an abort would occur.
The serialization order is ordered by the time they start, but the
time they commit. 
Multiple-version, each version has a WRITE timestamp followed by a
READ timestamp. There is no WRITE can be in between these two
timestamps.

\item Hybrid --- For best performance, you probably want a
hybrid of timestamps with two-phase locking in order to use less space
than pure timestamps but to allow more concurrency than timestamps.
For example, you could assign read/write transactions timestamps when
the commit, while read-only transactions would get timestamps when
they start.  Despite its advantages, most systems use two-phase
locking.

\item Optimistic --- Two-phase locking is pessimistic: The later
transaction blocks when it tries accessing earlier data, which besides
being inefficient can cause deadlock.  An optimistic strategy
processes your request immediately but keeps a list of reads and
writes and will abort transactions if they have done anything than
turns out to be impermissible.

The motivation for optimism is that the overhead for acquiring a lock
in two-phased locking is high, plus you might have to wait.  However,
the overhead of recording reads and writes is as expensive as locks,
plus you may do a lot of aborts, so optimism is not practical.
\end{enumerate}

Which method is best depends on the application.  In the absence of
information, however, you should first try two-phase locking and use
hybrid if that gives poor results.  (The literature has hundreds or
thousands of different methods.)

[At this point, there was a digression on how banks, ATMs, and
airlines keep track of transactions.  With banks and ATMs, the
consensus was that they still batch process at night in early 1970s.  
With airlines, it was pointed out that it's okay for their data to be
wrong, as long as it's not too far off and within an acceptable degree
of error, i.e. airlines purposely overbook anyway.]

\section{Different Commit Invariants}
Next, Weihl discussed the different commit invariants in the
specification of concurrent transactions, Handout 25, distributed last
time.  (A similar discussion appears on pages 4--5 of Handout 25.)
For all of these, no transactions' commit or abort directly causes the
commit or abort of another transaction, although the other transaction
may be unable to commit later as a result of the first transactions'
behavior.

\begin{itemize}
\item AC --- (All Committable); any subset of active transaction can
commit, and the committed transaction will still be serializable.
Other versions provide weaker guarantees. 

\item CC --- (Complete Commit); it's OK if all active transaction
commit as a group since they are serializable. This means that
tansactions commit in some order, but this is weaker saying any subset
of transaction can commit. 
There may be cascading aborts - reading uncommitted data.  
AC $\rightarrow$ CC. 

\item EO --- (Equal Opportunity); each transaction has some friends such
that it can commit if they do.  This means that for each transaction
there is someway to commit and still be serializable. 
When asked for an example that distinguished EO from CC, 
Weihl said that if a number of transactions
try writing and only the first one is allowed to commit.  On later
reflection, he and Lampson were unsure whether CC was actually
different from EO. 
But by definition, a transaction commit or abort doesn't make other
active transaction abort. Those transactions still remain active and
they have friends who can commit, so that they can commit and be
serializable. Anyway, the commit has to satisfy the invariant no
matter which version we pick. 

\item OD (Orphan Detection); every uncommitted transaction is
serializable with its base (i.e. set of transactions that have
committed at the time where the transaction starts)
and some subset of active transactions.
\end{itemize}
The last two methods in the handout, Optimistic Concurrency and No
Constraints, were not discussed.  (They are discussed in the handout.)

With any strategy, you want to be careful that no irreversible action
is done before a transaction commits, such as printing a ticket or
shooting off a missile.  This can be tricky if your output device is
unreliable, although Lampson didn't think it a big problem in
practice.  A more realistic problem is that a transaction might write
off the end of an array before realizing that something is wrong and
that it should abort.

Real commercial systems always try to hide as many of these details 
as possible.
For example, if you call routines in a database, these routines would
get locks, retry in case of deadlocks, etc.

\section{Distributed Systems Versus Centralized Systems}

\subsection{The Definition of a Distributed System}

Distributed systems can be described in two ways:
\begin{itemize}
\item Real-world definition: Computers (each of which acts as a
centralized system) can send messages to each other, but messages can
fail to be delivered or someone's system may crash, etc.  Our goal
with distributed systems is to get some useful work done, despite
these problems.
\item Abstract definition: When something fails on another system, the
whole system should not fail at once. This is in contrast to a
centralized system, where if something goes wrong, the whole system
crashes.  
\end{itemize}

For example, the United States telephone system should be designed as a
distributed system --- if one section goes down, the whole country's
phones shouldn't stop working.

In general, a distributed system is built to behave like a centralized
system with better uptime. Nowadays, people try to treat a distributed
system as a box and utilize the system as long as possible before
declaring the whole system is down.  Ideally, the system would
isolate failure so that the rest of system can still do some useful
work as opposed to the entire system having to reset itself.

The differences between centralized and distributed systems can be a
little fuzzy.  A multiprocessor is an example of a single computer
that is sometimes treated as a distributed system: If one task or
component fails, the whole system shouldn't go down.

While many properties of distributed systems can be abstracted away, a
critical property is communication.  Communication in a distributed
system is done by sending messages among centralized systems. It is
not possible to abstract away all the unreliability of physical
communication channels and to get just as reliable as a centralized
system.  Additionally, we do not want to abstract away the parallelism
available in a distributed system, or our algorithms will not make use
of it.

\subsection{Pragmatic Issues}

The advantages of using a distributed system are:
\begin{itemize}
\item Better cost/performance --- You get more computing cycles for your
dollar. 
\item Scalability --- You can change the size of the system
painlessly.  It's like what Joel Moses said fifteen years ago, when
contrasting APL with Lisp:  APL is like a diamond.  It's pretty, you
can admire it, but you can't change it.  Lisp is like mud.  When you
change it, it remains qualitatively the same thing.
\item Clustering --- Sometimes people would like to have computers
work together in cases where a centralized
management is impossible.  One example of this is the Internet, which links together
many computers managed by different organizations.
\item Geography --- It may be cheaper for you to install
your system in New Jersey, for example, instead of in the Wall Street
office area.  (This is not a fundamental issue.)
\item Higher availability --- Distributed systems usually have higher
availability than centralized systems
because multiple components provide redundancy, allowing work to
continue if some component fails.
\end{itemize}

The disadvantages of a distributed system are:
\begin{itemize}
\item Multiple namespaces --- Various clients have very
different views of the distributed system.  For example, ``foo'' on one
part of the system may mean something different from ``foo'' on
another part.

\item Less functionality --- Usually, a distributed system cannot
provide the same sort of functionality found in a centralized system,
such as being able to easily send your file to a printer. 

\item Availability --- Leslie Lamport's definition of a distributed
system is: ``My work doesn't get done if some computer I've never heard
of is down,'' with which the students agreed.  We'll talk
later in the course about how to get high availability.  Right now,
most systems are pretty bad.
\end{itemize}

None of the disadvantages are fundamental.  We know how to fix them in
theory.

\section{Coming Attractions}

The topic of distributed systems will continue, with:
\begin{itemize}
\item A discussion of communication primitives for distributed
systems.

\item A look at a distributed file system.
\end{itemize}

\end{document}