Appears in the Proceedings of the IEEE International Conference on Data Engineering, San Diego, CA, March 2000

Generalized Isolation Level Definitions

Atul Adya Barbara Liskov Patrick O’Neil

Microsoft Research, Laboratory for Computer Science, Univ. of Massachusetts,
1 Microsoft Way, Massachusetts Inst. of Technology, Boston, MA 02125-3393
Redmond, WA 98007 Cambridge, MA 02139 poneil@cs.umb.edu
adya@microsoft.com liskov@lcs.mit.edu

Abstract in [13] and some refinements suggested by [11] set the

stage for the ANSI/ISO SQL-92 definitions for isolation
Commercial databases support different isolation levels levels [6], where the goal was to develop a standard that
to allow programmers to trade off consistency for a poten- was implementation-independent. However, a subsequent
tial gain in performance. The isolation levels are defined in paper [8] showed that the definitions provided in [6] were
the current ANSI standard, but the definitions are ambigu- ambiguous. That paper proposed different definitions that
ous and revised definitions proposed to correct the problem avoided the ambiguity problems, but, as stated in [8], these
are too constrained since they allow only pessimistic (lock- definitions were simply “disguised versions of locking”
ing) implementations. This paper presents new specifica- and therefore disallow optimistic and multi-version mech-
tions for the ANSI levels. Our specifications are portable; anisms. Thus, these definitions fail to meet the goals of
they apply not only to locking implementations, but also to ANSI-SQL with respect to implementation-independence.
optimistic and multi-version concurrency control schemes. Thus, we have a problem: the standard is intended to be
Furthermore, unlike earlier definitions, our new specifica- implementation-independent, but lacks a precise definition
tions handle predicates in a correct and flexible manner at that meets this goal. Implementation-independence is im-
all levels. portant since it provides flexibility to implementors, which
can lead to better performance. Optimism can outperform
locking in some environments, such as large scale, wide-
1. Introduction area distributed systems [2, 15]; optimistic mechanisms are
the schemes of choice for mobile environments; and Gem-
stone [22] and Oracle [24] provide serializability and Snap-
This paper gives new, precise definitions of the ANSI-
shot Isolation, respectively, using multi-version optimistic
SQL isolation levels [6]. Unlike previous proposals [13, 6,
implementations. It is undesirable for the ANSI standard
8], the new definitions are both correct (they rule out all
to rule out these implementations. For example, Gemstone
bad histories) and implementation-independent. Our spec-
provides serializability even though it does not meet the
ifications allow a wide range of concurrency control tech-
locking-based rules given in [8].
niques, including locking, optimistic techniques [20, 2, 5],
This paper presents new implementation-independent
and multi-version mechanisms [9, 24]. Thus, they meet
specifications that correct the problems with the existing
the goals of ANSI-SQL and could be used as an isolation
definitions. Our definitions cover the weaker isolation lev-
standard.
els that are in everyday use: Most database vendors and
The concept of isolation levels was first introduced in [13] database programmers take advantage of levels below se-
under the name Degrees of Consistency. The goal of this rializability levels to achieve better performance; in fact,
work was to provide improved concurrency for workloads READ COMMITTED is the default for some database products
by sacrificing the guarantees of perfect isolation. The work and database vendors recommend using this level instead
of serializability if high performance is desired. Our defi-
Research of A. Adya and B. Liskov was supported in part by the ARPA nitions also enable database vendors to develop innovative
of the Department of Defense under contract DABT63-95-C-0005, moni- implementations of the different levels using a wide variety
tored by Fort Huachuca US Army Intelligence Center, and by NSF under
Grant IIS-98-02066. This research was done when Atul Adya was at MIT.
of concurrency control mechanisms including locking, op-
Research of P. O’Neil was supported by the NSF under Grant IRI-97-11374. timistic and multi-version mechanisms. Furthermore, our
specifications handle predicate-based operations correctly

1
at all isolation levels. 2. Previous Work
Thus, the paper makes the following contributions:
 It specifies the existing ANSI isolation levels in an
The original proposal for isolation levels [13] introduced
four degrees of consistency, degrees 0, 1, 2 and 3, where de-
implementation-independent manner. The definitions
gree 3 was the same as serializability. That paper, however,
are correct (they rule out all bad histories). They
was concerned with locking schemes, and as a consequence
are also complete (they allow all good histories) for
the definitions were not implementation-independent.
serializability; in particular, they provide conflict-
serializability [9]. It is difficult to prove completeness However, that work, together with the refinement of
for lower isolation levels, but we can easily show that the levels provided by Date [11], formed the basis for the
our definitions are more permissive than those given ANSI/ISO SQL-92 isolation level definitions [6]. The ANSI
in [8]. standard had implementation-independence as a goal and the
definitions were supposed to be less constraining than ear-
 Our specifications also handle predicates correctly in lier ones. The approach taken was to proscribe certain types
a flexible manner; earlier definitions were either lock- of bad behavior called phenomena; more restrictive consis-
based or incomplete [8]. tency levels disallow more phenomena and serializability
does not permit any phenomenon. The isolation levels were
Our approach can be used to define additional levels as well, named READ UNCOMMITTED, READ COMMITTED, REPEAT-
including commercial levels such as Cursor Stability [11], ABLE READ, and SERIALIZABLE; some of these levels were
and Oracle’s Snapshot Isolation and Read Consistency [24], intended to correspond to the degrees of [13].
and new levels; for example, we have developed an ad- The work in [8] analyzed the ANSI-SQL standard and
ditional isolation level called PL-2+, which is the weakest demonstrated several problems in its isolation level defini-
level that guarantees consistent reads and causal consistency tions: some phenomena were ambiguous, while others were
with respect to transactions. Details can be found in [1]. missing entirely. It then provided new definitions. As with
Our definitions are given using a combination of con- the ANSI-SQL standard, various isolation levels are defined
straints on transaction histories and graphs; we proscribe by having them disallow various phenomena. The phenom-
different types of cycles in a serialization graph at each ena proposed by [8] are:
isolation level. Our graphs are similar to those that have
been used before for specifying serializability [9, 19, 14], P0: w1 [x] ... w2 [x] ... (c1 or a1 )
semantics-based correctness criterion [4], and for defining P1: w1 [x] ... r2 [x] ... (c1 or a1 )
P2: r1 [x] ... w2 [x] ... (c1 or a1 )
extended transaction models [10]. Our approach is the first
P3: r1 [P] ... w2 [y in P] ... (c1 or a1 )
that applies these techniques to defining ANSI and commer-
cial isolation levels. Our specifications are different from the Proscribing P0 (which was missing in the ANSI-SQL defi-
multi-version theory presented in [9] since that work only nitions) requires that a transaction T2 cannot write an object
describes conditions for serializability whereas we specify x if an uncommitted transaction T1 has already modified
all ANSI/SQL-92 and other commercial isolation levels for x. This is simply a disguised locking definition, requiring
multi-version systems. Furthermore, unlike our specifica- T1 and T2 to acquire long write-locks. (Long-term locks
tions, their definitions do not take predicates into account. are held until the transaction taking them commits; short-
Our work is also substantially different from the definitions term locks are released immediately after the transaction
presented in [8] since our specifications handle multi-version completes the read or write that triggered the lock attempt.)
systems, optimistic systems and also deal with predicates in Similarly, proscribing P1 requires T1 to acquire a long write-
a correct and flexible manner at all isolation levels. lock and T2 to acquire (at least) a short-term read-lock, and
Relaxed correctness conditions based on semantics and proscribing P2 requires the use of long read and write locks.
extended transaction models have been suggested in the Phenomenon P3 deals with the queries based on predi-
past [10, 4, 17, 7]. By contrast, our work focuses on specify- cates. Proscribing P3 requires that a transaction T2 cannot
ing existing ANSI and commercial isolation levels that are modify a predicate P by inserting, updating, or deleting a
being used by large numbers of application programmers. row such that its modification changes the result of a query
The rest of this paper is organized as follows. Section 2 executed by an uncommitted transaction T 1 based on pred-
discusses prior work in more detail. Section 3 shows that the icate P; to avoid this situation, T1 acquires a long phantom
current definitions are inadequate and motivates the need for read-lock [14] on predicate P.
our work. Section 4 describes our database model. Section 5 Thus, these definitions only allow histories that would
provides our definitions for the existing ANSI isolation lev- occur in a system using long/short read/write item/predicate
els. We close in Section 6 with a discussion of what we have locks. Since locking serializes transactions by preventing
accomplished. certain situations (e.g., two concurrent transactions both

2
 Locking Isolation Level Proscribed Read Locks on Data Items and Write Locks on Data Items and
Phenomena Phantoms (same unless noted) Phantoms (always the same)
Degree 0 none none Short write locks
Degree 1 = Locking READ UNCOMMITTED P0 none Long write locks
Degree 2 = Locking READ COMMITTED P0, P1 Short read locks Long write locks
Locking REPEATABLE READ P0, P1, P2 Long data-item read locks, Long write locks
Short phantom read locks
Degree 3 = Locking SERIALIZABLE P0, P1, P2, P3 Long read locks Long write locks

Figure 1. Consistency Levels and Locking ANSI-92 Isolation Levels

modifying the same object), we refer to this approach as in mobile environments, where commits may take a long
the preventative approach. time if clients are disconnected from the servers [12, 16];
Figure 1 summarizes the isolation levels as defined in [8] furthermore, reads from uncommitted transactions may be
and relates them to a lock-based implementation. Thus desirable in high traffic hotspots [23]. For example, in his-
the READ UNCOMMITTED level proscribes P0; READ COM- tory H1 , if T2 reads T1 ’s values for both x and y, it can be
MITTED proscribes P0 and P1; the REPEATABLE READ level serialized after T1 :
proscribes P0 - P2; and SERIALIZABLE proscribes P0 - P3.
H10 : r1 (x, 5) w1 (x, 1) r1 (y, 5) w1 (y, 9) r2 (x, 1) r2 (y, 9) c1 c2

3. Restrictiveness of Preventative Approach The above history can occur in a mobile system, but P1
disallows it. In such a system, commits can be assumed to
We now show that the preventative approach is overly have happened “tentatively” at client machines [12, 16]; later
restrictive since it rules out optimistic and multi-version transactions may observe modifications of those tentative
implementations. As mentioned, this approach disallows transactions. When the client reconnects with the servers,
all histories that would not occur in a locking scheme and its work is checked to determine if consistency has been
prevents conflicting operations from executing concurrently. violated and the relevant transactions are aborted. Of course,
The authors in [8] wanted to ensure that multi-object con- if dirty reads are allowed, cascading aborts can occur, e.g.,
straints (e.g., constraints like x + y = 10) are not observed in history H10 , T2 must abort if T1 aborts; this problem can
as violated by transactions that request an isolation level be alleviated by using compensating actions [18, 26, 19].
such as serializability. They showed that histories such as Proscribing phenomenon P2 disallows a modification to
H1 and H2 are allowed by one interpretation of the ANSI an object that has been read by an uncommitted transaction
standard (at the SERIALIZABLE isolation level) even though (P3 rules out a similar situation with respect to predicates).
they are non-serializable: As with P0, uncommitted transactions may read/write the
H1 : r1 (x, 5) w1 (x, 1) r2 (x, 1) r2 (y, 5) c2 r1 (y, 5) w1 (y, 9) c1 same object concurrently in an optimistic implementation.
H2 : r2 (x, 5) r1 (x, 5) w1 (x, 1) r1 (y, 5) w1 (y, 9) c1 r2 (y, 9) c2 There is no harm in allowing phenomenon P2 if transactions
In both cases, T2 observes an inconsistent state (it observes commit in the right order. For example, in history H 2 given
invariant x + y = 10 to be violated). These histories are not above, if T2 reads the old values of x and y, the transactions
allowed by the preventative approach; H 1 is ruled out by P1 can be serialized in the order T2 ; T1 :
and H2 is ruled out by P2.
H20 : r2 (x, 5) r1 (x, 5) w1 (x, 1) r1 (y, 5) r2 (y, 5) w1 (y, 9) c2 c1
Optimistic and multi-version mechanisms [2, 5, 9, 20, 22]
that provide serializability also disallow non-serializable The real problem with the preventative approach is that
histories such as H1 and H2 . However, they allow many the phenomena are expressed in terms of single-object his-
legal histories that are not permitted by P0, P1, P2, and P3. tories. However, the properties of interest are often multi-
Thus, the preventative approach disallows such implemen- object constraints. To avoid problems with such constraints,
tations. Furthermore, it rules out histories that really occur the phenomena need to restrict what can be done with indi-
in practical implementations. vidual objects more than is necessary. Our approach avoids
Phenomenon P0 can occur in optimistic implementations this difficulty by using specifications that capture constraints
since there can be many uncommitted transactions modify- on multiple objects directly. Furthermore, the definitions in
ing local copies of the same object concurrently; if neces- the preventative approach are not applicable to multi-version
sary, some of them will be forced to abort so that serializ- systems since they are described in terms of objects rather
ability can be provided. Thus, disallowing P0 can rule out than in terms of versions. On the other hand, our specifica-
optimistic implementations. tions deal with multi-version and single-version histories.
Condition P1 precludes transactions from reading up- The approach in [8] only allows schemes that provide
dates by uncommitted transactions. Such reads are disal- the same guarantees for running and committed transac-
lowed by many optimistic schemes, but they are desirable tions (a lock-based implementation does indeed have this

3
property). However, many optimistic mechanisms provide database creates the initial visible versions of the objects
weak guarantees to transactions as they run while provid- being inserted. When a transaction Ti deletes an object x
ing strong guarantees such as serializability for committed (e.g., by deleting a tuple from some relation), we model it
transactions. Our definitions allow different isolation guar- as the creation of a special dead version, i.e., in this case,
antees for committed and running transactions; in this paper, xi is a dead version. Thus, object versions can be of three
we only present guarantees for committed transactions. kinds — unborn, visible, and dead; the ordering relationship
between these versions is discussed in Section 4.2.
4. Database Model and Transaction Histories If an object x is deleted from the committed database
state and inserted later, we consider the two incarnations of
x to be distinct objects. When a transaction Ti performs an
We now describe our database model, transaction histo-
insert operation, the system selects a unique object x that
ries, and serialization graphs. We use a multi-version model
has never been selected for insertion before and T i creates a
similar to the one presented in [9]. However, unlike [9], our
visible version of x if it commits.
model incorporates predicates also. Furthermore, we al-
low predicate behavior that is possible in non-locking based We assume object versions exist forever in the committed
systems. state to simplify the handling of inserts and deletes, i.e., we
simply treat inserts/deletes as write (update) operations. An
implementation only needs to maintain visible versions of
4.1. Database Model
objects, and a single-version implementation can maintain
just one visible version at a time. Furthermore, application
The database consists of objects that can be read or writ-
transactions in a real system access only visible versions.
ten by transactions; in a relational database system, each
row or tuple is an object. Each transaction reads and writes
objects and indicates a total order in which these operations 4.2. Transaction Histories
occur.
An object has one or more versions. However, trans- We capture what happens in an execution of a database
actions interact with the database only in terms of objects; system by a history. A history H over a set of transactions
the system maps each operation on an object to a specific consists of two parts — a partial order of events E that
version of that object. A transaction may read versions reflects the operations (e.g., read, write, abort, commit) of
created by committed, uncommitted, or even aborted trans- those transactions, and a version order, , that is a total
actions; constraints imposed by some isolation levels will order on committed versions of each object.
prevent certain types of reads, e.g., reading versions created Each event in a history corresponds to an operation of
by aborted transactions. some transaction, i.e., read, write, commit, or abort. A write
When a transaction writes an object x, it creates a new operation on object x by transaction T i is denoted by wi (xi )
version of x. A transaction Ti can modify an object multiple (or wi (xi:m )); if it is useful to indicate the value v being
times; its first modification of object x is denoted by xi:1 , written into xi , we use the notation, wi (xi , v). When a
the second by xi:2 , and so on. Version xi denotes the final transaction Tj reads a version of x that was created by Ti ,
modification of x performed by T i before it commits or we denote this as rj (xi ) (or rj (xi:a )). If it is useful to indicate
aborts. A transaction’s last operation, commit or abort, the value v being read, we use the notation r j (xi , v).
indicates whether its execution was successful or not; there The partial order of events E in a history obeys the fol-
is at most one commit or abort operation for each transaction. lowing constraints:
The committed state reflects the modifications of com-  It preserves the order of all events within a transaction
mitted transactions. When transaction Ti commits, each including the commit and abort events.
version xi created by Ti becomes a part of the committed
state and we say that Ti installs xi ; the system determines  If an event rj (xi:m ) exists in E, it is preceded by
the ordering of x i relative to other committed versions of x. wi (xi:m ) in E, i.e., a transaction Tj cannot read ver-
If Ti aborts, xi does not become part of the committed state. sion xi:m of object x before it has been produced by
Conceptually, the initial committed state comes into ex- Ti . Note that the version read by Tj is not necessarily
istence as a result of running a special initialization trans- the most recently installed version in the committed
action, Tinit . Transaction Tinit creates all objects that will database state; also, Ti may be uncommitted when
ever exist in the database; at this point, each object x has rj (xi:m ) occurs.
an initial version, xinit , called the unborn version. When  If an event wi (xi:m ) is followed by ri (xj ) without an
an application transaction creates an object x (e.g., by in- intervening event wi (xi:n ) in E, xj must be xi:m . This
serting a tuple in a relation), we model it as the creation of condition ensures that if a transaction modifies object
a visible version for x. Thus, a transaction that loads the x and later reads x, it will observe its last update to x.

4
  The history must be complete: if E contains a read 4.3. Predicates
or write event that mentions a transaction Ti , E must
contains a commit or abort event for T i . We now discuss how predicates are handled in our model.
We assume that predicates are used with relations in a rela-
A history that is not complete can be completed by append- tional database system. There are three types of modification
ing abort events for uncommitted transactions in E. Adding operations on relations: updates, inserts and deletes; inserts
these events is intuitively correct since any implementation and deletes change the number of tuples in a relation.
that allows a commit of a transaction that reads from an In our model, the database is divided into relations and
uncommitted transaction Ti can do so only if it is legal for each tuple (and all its versions) exists in some relation. As
Ti to abort later. before, unborn and dead versions exist for a tuple before the
For convenience, we will present event histories in ex- tuple’s insertion and after its deletion. An important point
amples as a total order (from left to right) that is consistent to note here is that a tuple’s relation is known in our model
with the partial order. when the database is initialized by Tinit , i.e., before the
The second part of a history H is the version order, , that tuple is inserted by an application transaction. Of course,
specifies a total order on versions of each object created by this assumption is needed only at a conceptual level. In an
committed transactions in H; there is no ordering of versions implementation, the system need not know the relation of
due to uncommitted or aborted transactions. We also refer all tuples that will be created in the system; it just needs to
to versions due to committed transactions in H as committed know a tuple x’s relation when x is inserted in the database.
versions. We impose two constraints on a history’s version A predicate P identifies a Boolean condition (e.g., as in
order for different kinds of committed versions: the WHERE clause of a SQL statement) and the relations on
 the version order of each object x contains exactly one
which the condition has to be applied; one or more relations
can be specified in P. All tuples that match this condition are
initial version, xinit , and at most one committed dead
read or modified depending on whether a predicate-based
version, xdead .
read or write is being considered.
 xinit is x’s first version in its version order and xdead
is its last version (if it exists); all committed visible Definition 1 : Version set of a predicate-based operation.
versions are placed between xinit and xdead . When a transaction executes a read or write based on a
predicate P, the system selects a version for each tuple in
We additionally constrain the system to allow reads only P’s relations. The set of selected versions is called the
of visible versions: Version set of this predicate-based operation and is denoted
 if rj (xi ) occurs in a history, then xi is a visible version.
by Vset(P).

For convenience, we will only show the version order for The version set defines the state that is observed to eval-
visible versions in our example histories; in cases where uate a predicate P; as discussed later, P’s Boolean condition
unborn or dead versions help in illustrating an issue, we will is applied on the versions in Vset(P) to determine which
show some of these versions as well. tuples satisfy P. Since we select a version for all possible
tuples in P’s relations, this set will be very large (it includes
The version order in a history H can be different from
unborn and possibly dead versions of some tuples). For
the order of write or commit events in H. This flexibility is
convenience, in our examples we will only show visible ver-
needed to allow certain optimistic and multi-version imple-
sions in a version set; to better explain some examples, we
mentations where it is possible that a version xi is placed
before version xj in the version order (x i  xj ) even though
will sometimes also show some unborn and dead versions.
Our approach of observing some version of each tuple
xi is installed in the committed state after version xj was
allows us to handle the phantom problem [14] in a simple
installed. For example, in history Hwrite;order ,
manner. Of course, this does not constrain implementations
H write;order : w1 (x1 ) w2 (x2 ) w2 (y2 ) c1 c2 to perform these observations; e.g., an implementation could
r3 (x1 ) w3 (x3 ) w4 (y4 ) a4 [x2  x1 ] use an index.

the database system has chosen the version order x 2  x1

4.3.1 Predicate-based Reads
even though T1 commits before T2 . Note that there are no
constraints on x3 (yet) or y4 since these versions correspond If a transaction Ti performs reads based on a predicate P
to uncommitted and aborted transactions, respectively. Note (e.g., in a SQL statement), the system (conceptually) ac-
also that the naming of transactions does not indicate their cesses all versions in Vset(P). Then, the system determines
commit order, e.g., in history H write;order , T2 is serialized which tuples match predicate P by evaluating P’s Boolean
before T1 . condition on the versions in Vset(P); tuples whose unborn

5
and dead versions were selected in the previous step do not T1 : INSERT INTO BONUS SELECT NAME, SAL, COMM
match. If the system reads the matched versions as part FROM EMP WHERE COMM > 0.25 * SAL;
of the query, these reads show up as separate events in the Here is a possible history for T1 ’s execution in our model:
history. Thus, a query based on a predicate P by T i is repre-
sented in a history as ri (P: Vset(P)) ri (xj ) ri (yk ) : : :, where H insert : r1 (comm > 0.25 * sal: x0 , z0 ) r1 (x0 ) w1 (y1 ) c1
xj , yk are the versions in Vset(P) that match P, and Ti reads In this history, x0 matches the predicate-based query; there-
these versions. If Ti does not read the matched objects, the fore it is read by T1 to generate tuple y1 that is inserted into
events ri (xj ) and ri (yk ) do not show up in the history, e.g., the Bonus table.
Ti could simply use the count of tuples that matched P.
For example, suppose transaction Ti executes the follow- 4.4. Conflicts and Serialization Graphs
ing SQL query:
SELECT * FROM EMPLOYEE WHERE DEPT = SALES; We first define the different types of read/write conflicts
This query (conceptually) accesses a version of every visible that can occur in a database system and then use them to
tuple in the Employee relation (e.g., x 1 and y2 ) and the specify serialization graphs. We define three kinds of di-
unborn/dead versions of other tuples in this relation (e.g., rect conflicts that capture conflicts of two different commit-
zinit ). Suppose that version x1 matches the predicate and ted transactions on the same object or intersecting predi-
y2 does not match; recall that unborn versions such as z init cates. For convenience, we have separated the definitions of
cannot match the predicate. This predicate-based read could predicate-based conflicts and regular conflicts.
be shown in a history as ri (Dept=Sales: x1 ; y2 ) ri (x1 ); here,
we do not show unborn or dead versions in the version set. 4.4.1 Read Dependencies
Note that the read of x1 shows up as a separate event in
Read dependencies occur when one transaction reads a rel-
the history; if Ti had just determined the number of tuples
evant version produced by some other transaction. We use
matching the predicate (using SELECT COUNT), the event
the following definition for specifying read-dependencies:
ri (x1 ) would not have been included.Thus, the history only
shows reads of versions that were actually observed by T i . Definition 2 : Change the Matches of a Predicate-Based
Read. We say that a transaction Ti changes the matches
4.3.2 Predicate-based Modifications of a predicate-based read r j (P: Vset(P)) if Ti installs xi , xh
immediately precedes xi in the version order,and x h matches
A modification based on a predicate P is modeled as a
P whereas xi does not or vice-versa. In this case, we also
predicate-based read followed by write operations on tuples
say that xi changes the matches of the predicate-based read.
that match P. (Although this approach is weaker than the one
used in [1], it models the behavior of commercial databases.) The above definition identifies Ti to be a transaction where
For example, suppose transaction Ti executes the following a change occurs for the matched set of r j (P: Vset(P)).
code for the employee database discussed above:
UPDATE EMPLOYEE SAL = SAL + $10 WHERE DEPT=SALES; Definition 3 : Directly Read-Depends. We say that Tj
Suppose that the system selects versions, x1 , y2 , and zinit directly read-depends on transaction Ti if it directly item-
for this operation. If x 1 matches the predicate but y2 and read-depends or directly predicate-read-depends on T i .
zinit do not, the following events are added to the history:
ri (Dept=Sales: x1 ; y2 ) wi (xi ). Directly item-read-depends: We say that Tj directly item-
If the predicate-based write deletes objects, dead versions read-depends on Ti if Ti installs some object version
are installed for all the matching tuples (i.e., these tuples are xi and Tj reads xi .
deleted). Thus, if a transaction Ti deletes all employees from Directly predicate-read-depends: Transaction Tj directly
the Sales department in the above scenario, the following predicate-read-depends on T i if Tj performs an oper-
events are added to the history: ri (Dept=Sales: x1 ; y2 ) wi (xi , ation rj (P: Vset(P)), xk 2 Vset(P), i = k or xi  xk ,
dead). Note that the events for deletes and updates are and xi changes the matches of rj (P: Vset(P)).
similar. However, there is a difference: in the deletion
example, xi is a dead version (for illustrative purposes, we If Tj performs a predicate-based read r j (P: Vset(P)), it
have shown the value “dead” being put in x i ) and cannot be read depends on Ti if Ti performs a write that is “relevant” to
used further whereas in the update case, x i can be used later. Tj ’s read, i.e., Ti is a transaction before Tj that changed the
Inserts are handled in a similar manner. For exam- matches of Tj ’s read. Note that all tuples in the version set
ple, consider the following statement that copies employ- of a predicate-based read are considered to be accessed, in-
ees whose commission exceeds 25% of their salary into the cluding tuples that do not match the predicate. The versions
BONUS table (this statement is executed by transaction T1 ): that are actually read by transaction Tj show up as normal

6
read events. Other versions in the version set are essen- Read-dependencies and anti-dependencies are treated
tially ghost reads, i.e., their values are not observed by the similarly for predicates, i.e., we add an edge whenever a
predicate-based read but read-dependencies are established predicate’s matched set is changed. The difference between
for them as well. item-anti-depends and predicate-anti-depends is also simi-
The rule for predicate-read-dependencies captures the lar. For item-anti-depends, the overwriting transaction must
idea that what matters for a predicate is the set of tuples that produce the very next version of the read object, while for
match or do not match and not their values. Furthermore, of predicate-anti-depends it simply produces a later version
all the transactions that have caused the tuples to match (or that changes the matched tuples of the predicate.
not match) for rj (P: Vset(P)), we use the latest transaction The definition for predicate-anti-depends handles inserts
where a change to Vset(P) occurs rather than using the latest and deletes. For example, consider the employee database
transaction that installed the versions in Vset(P). This rule scenario described in Section 4.3 that contains visible ver-
ensures that we capture the minimum possible conflicts for sions of two tuples x and y. Suppose Ti executes a query
predicate-based reads. For example, consider the history: that selects all Employees in the Sales department, and the
query’s version set contains versions x1 and y2 (along with
H pred;read : w0 (x0 ) c0 w1 (x1 ) c1 w2 (x2 )
r3 (Dept=Sales: x2 , y0 ) w2 (y2 ) c2 c3 [x0  x1  x2 , y0  y2 ] unborn/dead versions of other tuples), and x 1 is in Sales
and y2 is not. A later transaction Tj will directly predicate-
Here, transaction T0 inserts object x in the Sales department, anti-depend on Ti if Tj adds a new employee to the Sales
T1 changes x’s department to Legal, and T 2 changes the department, moves y to Sales, removes x from Sales, or
phone number of x but not its department. Transaction T 3 deletes x from the database.
selects all employees in the Sales department. In this case, In a two-phase locking implementation (for providing
even though T3 ’s version set contains x2 , we add a predicate- serializability), if a transaction T1 performs a read based on
read-dependency from T 1 to T3 because T2 ’s update of x is predicate P and T2 tries to insert an object x covered by P’s
irrelevant for T3 ’s read. Note that this history is serializable predicate lock, T2 is delayed till T1 finishes. In our model,
in the order T0 , T1 , T3 , T2 . T1 reads xinit and T2 creates a later version x2 . If T2 changes
the matches by T1 ’s read, T2 predicate-anti-depends on T 1 .
4.4.2 Anti-Dependencies Note that T1 ’s predicate read-locks delay T2 even if T2 does
not change the objects matched by P. Our definitions are
An anti-dependency occurs when a transaction overwrites a more flexible and permit implementations that allow T2 to
version observed by some other transaction. proceed in such cases, e.g., precision locks and granular
To define anti-dependencies, it is useful to define what it locks [14].
means to overwrite a predicate-based operation.

Definition 4 : Overwriting a predicate-based read. 4.4.3 Write Dependencies

We say that a transaction Tj overwrites an operation
ri (P: Vset(P)) if Tj installs xj such that xk 2 Vset(P), Write dependencies occur when one transaction overwrites
xk  xj , and xj changes the matches of ri (P: Vset(P)). a version written by another transaction.
Definition 6 : Directly Write-Depends. A transaction Tj
Now we can define anti-dependencies. directly write-depends on Ti if Ti installs a version xi and
Tj installs x’s next version (after xi ) in the version order.
Definition 5 : Directly Anti-Depends. Transaction Tj di-
rectly anti-depends on transaction Ti if it directly item-anti-
Note that there is no notion of predicate-write-depends since
depends or directly predicate-anti-depends on T i .
predicate-based modifications are modeled as queries fol-
Directly item-anti-depends: We say that Tj directly item- lowed by writes on individual tuples.
anti-depends on transaction T i if Ti reads some object
version xk and Tj installs x’s next version (after xk ) 4.4.4 Serialization Graphs
in the version order. Note that the transaction that
wrote the later version directly item-anti-depends on Now we can define the Direct Serialization Graph or DSG.
the transaction that read the earlier version. This graph is called “direct” since it is based on the direct
conflicts discussed above. In the graph we will denote direct
Directly predicate-anti-depends: We say that Tj directly wr
predicate-anti-depends on T i if Tj overwrites an oper- read-dependencies by Ti
ww
;! j , direct write-dependencies
T
rw
ation ri (P: Vset(P)), i.e., Tj installs a later version of by Ti ;! Tj , and direct anti-dependencies by Ti ;! Tj .
some object that changes the matches of a predicate- Figure 2 summarizes this notation and reviews the defini-
based read performed by T i . tions for direct dependencies.

7
 Conflicts Name Description (Tj conflicts on Ti ) Notation in DSG

ww
Directly write-depends Ti installs xi and Tj installs x’s next version Ti ! Tj
wr
Directly read-depends Ti installs xi , Tj reads xi or Tj performs a predicate-based Ti ! Tj
read, xi changes the matches of Tj ’s read, and xi is the same
or an earlier version of x in Tj ’s read
rw
Directly anti-depends Ti reads xh and Tj installs x’s next version or Ti performs a T i ; ; ! Tj
predicate-based read and Tj overwrites this read

Figure 2. Definitions of direct conflicts between transactions.

Definition 7 : Direct Serialization Graph. we disallow undesirable situations while allowing histories
We define the direct serialization graph arising from a that are permitted by a variety of implementations.
history H, denoted by DSG(H), as follows. Each node in the Like the previous approaches, we will define each iso-
graph corresponds to a committed transaction and directed lation level in terms of phenomena that must be avoided at
edges correspond to different types of direct conflicts. There each level. Our phenomena are prefixed by “G” to denote
is a read/write/anti-dependency edge from transaction Ti to the fact that they are general enough to allow locking and op-
transaction Tj if Tj directly read/write/anti-depends on Ti . timistic implementations; these phenomena are named G0,
G1, and so on (by analogy with P0, P1, etc of [6]). We will
A DSG does not capture all information in a history and refer to the new levels as PL levels (where PL stands for
hence it does not replace the history, e.g., a DSG only records “portable level”) to avoid the possible confusion with the
information about committed transactions. The history is degrees of isolation given in [8, 13].
still available if needed, and in fact, we use the history
instead of the DSG for some conditions.
As an example, consider the following history: 5.1. Isolation Level PL-1
H serial : w1 (z1 ) w1 (x1 ) w1 (y1 ) w3 (x3 ) c1 r2 (x1 ) w2 (y2 )
c2 r3 (y2 ) w3 (z3 ) c3 [x1  x3 , y1  y2 , z1  z3 ] Disallowing phenomenon P0 ensures that writes per-
formed by T1 are not overwritten by T2 while T1 is still
Figure 3 shows the DSG for this history. As we can see, uncommitted. There seem to be two reasons why this pro-
these transactions are serializable in the order T1 ; T2 ; T3 . scription might be desirable:
wr rw
1. It simplifies recovery from aborts. In the absence of this
ww wr proscription, a system that allows writes to happen in
T1 T2 T3
place cannot recover the pre-states of aborted transac-
ww tions using a simple undo log approach. For example,
suppose T1 updates x (i.e., w1 (x1 )), T2 overwrites x,
Figure 3. DSG for history Hserial and then T1 aborts. The system must not restore x to
T1 ’s pre-state. However, if T2 aborts later, x must be
It is also useful to have additional dependency relations:
restored to T1 ’s pre-state and not to x1 .
Definition 8 : Depends. A transaction Tj directly depends 2. It serializes transactions based on their writes alone.
on Ti if Tj directly write-depends or directly read-depends For example, if T2 updates an object x and T1 overwrites
on Ti . We say that Tj depends on Ti in H if there is a x, there should not be another object y in which the
path from Ti to Tj in DSG(H) consisting of one or more reverse occurs, i.e., all writes of T2 must be ordered
dependency edges. before or after all writes of T1 .

5. New Generalized Isolation Specifications The first reason does not seem relevant to all systems.
Instead, it is based on a particular implementation of recov-
We now present our specifications for the existing ANSI ery, and other implementations are possible. For example,
isolation levels. We developed our conditions by studying the Thor system [21] maintains temporary versions of ob-
the motivation of the original definitions [13] and the prob- jects for an uncommitted transaction Ti and discards these
lems that were addressed by the phenomena in [8]. This versions if Ti aborts.
enabled us to develop implementation-independent specifi- Serializing transactions based on writes is a useful prop-
cations that capture the essence of the ANSI definitions, i.e., erty since it ensures that updates of conflicting transactions

8
are not interleaved. This property is captured by phe- 1. It prevents a transaction T2 from committing if T2 has
nomenon G0 and we define PL-1 as the level in which read the updates of a transaction that might later abort.
G0 is disallowed: 2. It prevents transactions from reading intermediate mod-
G0: Write Cycles. A history H exhibits phenomenon ifications of other transactions.
G0 if DSG(H) contains a directed cycle consisting 3. It serializes committed transactions based on
entirely of write-dependency edges. their read/write-dependencies (but not their anti-
dependencies). That is, if transaction T2 depends on
For example, history Hwcycle T1 , T1 cannot depend on T 2 .
H wcycle : w1 (x1 , 2) w2 (x2 , 5) w2 (y2 , 5) c2 w1 (y1 , 8) c1
[x1  x2 , y2  y1 ] Disallowing P1 (together with P0) captures all three of these
is disallowed by PL-1 because the updates on x and y occur issues, but does so by preventing transactions from reading
in opposite orders, causing a cycle in the graph. Figure 4 or writing objects written by transactions that are still un-
shows the DSG for this history. committed. Instead, we address these three issues by the
following three phenomena, G1a, G1b, and G1c.
ww
ww G1a: Aborted Reads. A history H shows phe-
T1 T2 nomenon G1a if it contains an aborted transaction
T1 and a committed transaction T2 such that T2 has
Figure 4. DSG for history Hwcycle read some object (maybe via a predicate) modified by
Our PL-1 specification is more permissive than Degree 1 T1 . Phenomenon G1a can be represented using the
of [8] since G0 allows concurrent transactions to modify the following history fragments:
same object whereas P0 does not. Thus, non-serializable w1 (x1:i ) ::: r2 (x1:i ) : : : (a1 and c2 in any order)
interleaving of write operations is possible among uncom- w1 (x1:i ) ::: r2 (P: x1:i , ...) ::: (a1 and c2 in any order)
mitted transactions as long as such interleavings are dis-
allowed among committed transactions (e.g., by aborting Proscribing G1a ensures that if T2 reads from T1 and T1
some transactions). aborts, T2 must also abort; these aborts are also called cas-
The lock-based implementation of PL-1 (long write- caded aborts [9]. In a real implementation, the condition
locks) disallows G0 since two concurrent transactions, Ti also implies that if T2 reads from an uncommitted transac-
and Tj , cannot modify the same object; therefore, all writes tion T1 , T2 ’s commit must be delayed until T1 ’s commit has
of Tj either precede or follow all writes of Ti . succeeded [9, 14].
Note that since predicate-based modifications are mod-
eled as queries followed by normal writes, PL-1 provides G1b: Intermediate Reads. A history H shows phe-
weak guarantees for such updates. For example, consider nomenon G1b if it contains a committed transaction
the following history in which transaction T 2 increments the T2 that has read a version of object x (maybe via a
salaries of all employees for which “Dept = Sales”, and T1 predicate) written by transaction T1 that was not T1 ’s
adds two employees, x and y, to the Sales department. final modification of x. The following history frag-
ments represent this phenomenon:
H pred;update : w1 (x1 ) r2 (Dept=Sales: x1 ; yinit ) w1 (y1 )
w2 (x2 ) c1 c2 [xinit  x1  x2 , yinit  y1 ] w1 (x1:i ) ::: r2 (x1:i ) : : : w1 (x1:j ) : : : c2
w1 (x1:i ) ::: r2 (P: x1:i ; :::) : : : w1 (x1:j ) : : : c2
The updates of transactions T1 and T2 are interleaved in this
history (x’s salary is updated but y’s salary is not). This inter- Proscribing G1b ensures that transactions are allowed to
leaving is allowed at PL-1 since there is no write-dependency commit only if they have read final versions of objects cre-
cycle in the DSG (there is a write-dependency edge from T 1
to T2 since x1  x2 ).
ated by other transactions. Note that disallowing G1a and
G1b ensures that a committed transaction has read only ob-
ject states that existed (or will exist) at some instant in the
5.2. Isolation Level PL-2 committed state.

If a system disallows only G0, it places no constraints on G1c: Circular Information Flow. A history H ex-
reads: a transaction is allowed to read modifications made hibits phenomenon G1c if DSG(H) contains a directed
by committed, uncommitted, or even aborted transactions. cycle consisting entirely of dependency edges.
Proscribing phenomenon P1 in [6] was meant to ensure that
T1 updates could not be read by T 2 while T1 was still un- Intuitively, disallowing G1c ensures that if transaction T2 is
committed. There seem to be three reasons why disallowing affected by transaction T1 , it does not affect T1 , i.e., there
P1 (in addition to P0) might be useful: is a unidirectional flow of information from T 1 to T2 . Note

9
that G1c includes G0. We could have defined a weaker wr
version of G1c that only concerned cycles with at least one predicate - rw
read-dependency edge, but it seemed simpler not to do this. T1 T2
Phenomenon G1 captures the essence of no-dirty-reads
Figure 5. Direct serialization graph for history
and is comprised of G1a, G1b and G1c. We define isolation
Hphantom (T0 is not shown)
level PL-2 as one in which phenomenon G1 is disallowed.
Proscribing G1 is clearly weaker than proscribing P1 since
G1 allows reads from uncommitted transactions. The lock- 5.4. Isolation Level PL-2.99
based implementation of PL-2 disallows G1 because the
combination of long write-locks and short read-locks en- The level called REPEATABLE READ or Degree 2.99
sures that if Ti reads a version produced by T j , Tj must in [6] provides less than full serializability with respect to
have committed already (i.e., G1a, G1b not possible) and predicates. In particular, it uses long locks for all operations
therefore Tj cannot read a version produced by T i (i.e., G1c except predicate reads for which it used short locks, i.e.,
not possible). it ensures serializability with respect to regular reads and
Our PL-2 definition treats predicate-based reads like nor- provides guarantees similar to degree 2 for predicate reads.
mal reads and provides no extra guarantees for them; we Thus, anti-dependency cycles due to predicates can occur at
believe this approach is the most useful and flexible. Other this level.
approaches, such as requiring that each predicate-based op- We define level PL-2.99 as one that proscribes G1 and
eration is atomic with respect to other predicate-based oper- G2-item:
ations, are discussed in [1].
G2-item: Item Anti-dependency Cycles. A his-
5.3. Isolation Level PL-3 tory H exhibits phenomenon G2-item if DSG(H) con-
tains a directed cycle having one or more item-anti-
In a system that proscribes only G1, it is possible for a dependency edges.
transaction to read inconsistent data and therefore to make
inconsistent updates. Although disallowing phenomenon P2 For example, consider the following history:
prevents such situations (e.g., H2 presented in Section 3),
it also prevents legal histories such as H20 (which is also
H phantom : r1 (Dept=Sales: x0 , 10; y0 , 10) r1 (x0 , 10) r2 (y0 , 10)
r2 (Sum0 , 20) w2 (z2 , 10) w2 (Sum2 , 30) c2 r1 (Sum2 , 30) c1
discussed in Section 3) and hence, disallows many optimistic [Sum0  Sum2 , zinit  z2 ]
and multi-version concurrency control schemes. What we
need is to prevent transactions that perform inconsistent When T1 performs its query, there are exactly two employ-
reads or writes from committing. This is accomplished by ees, x and y, both in Sales (we show only visible versions
the following condition: in the history). T1 sums up the salaries of these employees
and compares it with the sum-of-salaries maintained for this
G2: Anti-dependency Cycles. A history H exhibits
department. However, before it performs the final check, T 2
phenomenon G2 if DSG(H) contains a directed cycle
inserts a new employee, z2 , in the Sales department, updates
with one or more anti-dependency edges.
the sum-of-salaries, and commits. Thus, when T1 reads the
We define PL-3 as an isolation level that proscribes G1 and new sum-of-salaries value it finds an inconsistency.
G2. Thus, all cycles are precluded at this level. Of course, The DSG for Hphantom is shown in Figure 5. This his-
the lock-based implementation of PL-3 (long read/write- tory is ruled out by PL-3 but permitted by PL-2.99 because
locks) disallows phenomenon G2 also since two-phase lock- the DSG contains a cycle only if predicate anti-dependency
ing is known to provide complete serializability. edges are considered.
Proscribing G2 is weaker than proscribing P2, since we
allow a transaction Tj to modify object x even after another 5.5. Mixing of Isolation Levels
uncommitted transaction Ti has read x. Our PL-3 definition
allows histories such as H10 and H20 (presented in Section 3) So far, we have only discussed systems in which all trans-
that were disallowed by the preventative definitions. actions are provided the same guarantees. However, in gen-
The conditions given in [9] provides view-serializability eral, applications may run transactions at different levels and
whereas our specification for PL-3 provides conflict- we would like to understand how these transactions interact
serializability (this can be shown using theorems presented with each other. This section discusses how we model such
in [9]). All realistic implementations provide conflict- mixed systems.
serializability; thus, our PL-3 conditions provide what is In real database systems, each SQL statement in a trans-
normally considered as serializability. action Ti may be executed atomically even though T i is

10
 Level Phenomena Informal Description (Ti can commit only if:)
disallowed
PL-1 G0 Ti ’s writes are completely isolated from the writes of other transactions
PL-2 G1 Ti has only read the updates of transactions that have committed by the time Ti
commits (along with PL-1 guarantees)
PL-2.99 G1, G2-item Ti is completely isolated from other transactions with respect to data items and
has PL-2 guarantees for predicate-based reads
PL-3 G1, G2 Ti is completely isolated from other transactions, i.e., all operations of Ti are
before or after all operations of any other transaction

Figure 6. Summary of portable ANSI isolation levels

executed at a lower isolation level. Mixed systems in which to the MSG. The reason is that an MSG considers the pres-
individual SQL statements are executed atomically are dis- ence of transactions at other levels whereas a DSG is simply
cussed in [1]. constructed with all edges. An MSG is useful for determin-
In a mixed system, each transaction specifies its level ing correctness if PL-1 and PL-2 transactions “know” what
when it starts and this information is maintained as part of they are doing whereas a DSG ensures correctness without
the history and used to construct a mixed serialization graph making any assumptions about the operations of lower level
or MSG. Like a DSG, the MSG contains nodes correspond- transactions.
ing to committed transactions and edges corresponding to A mixed system can be implemented using locking (with
dependencies, but only dependencies relevant to a transac- the standard combination of short and long read/write locks).
tion’s level or obligatory dependencies show up as edges in But it can also be implemented using other techniques. For
the graph. Transaction Ti has an obligatory conflict with example an optimistic implementation would attempt to fit
transaction Tj if Tj is running at a higher level than T i , each committing transaction into the serial order based on
Ti conflicts with Tj , and the conflict is relevant at Tj ’s its own requirements (for its level) and its obligations to
level. For example, an anti-dependency edge from a PL-3 transactions running at higher levels, and would abort the
transaction to a PL-1 transaction is an obligatory edge since transaction if this is not possible. An optimistic implemen-
overwriting of reads matters at level PL-3. tation that is mixing-correct is presented in [1].
Edges are added as follows: Since write-dependencies
are relevant at all levels, we retain all such edges. For 5.6. Discussion
a PL-2 or PL-3 node Ti , since reads are important, read-
dependencies coming into T i are added. Similarly, we add
all outgoing anti-dependency edges from PL-3 transactions We summarize the isolation levels discussed in this sec-
to other nodes. tion in Figure 6.
Now we can define correctness for a mixed history: These levels are defined to impose constraints only when
transactions commit; they do not constrain transactions as
Definition 9 : Mixing-Correct. A history H is mixing- they run, although if something bad happens (e.g., a PL-
correct if MSG(H) is acyclic and phenomena G1a and G1b 3 transactions observes an inconsistency), they do force
do not occur for PL-2 and PL-3 transactions. aborts. Analogs of the levels that constrain executing trans-
actions are given in [1]; these definitions use slightly dif-
It is possible to restate the above definition as an analog ferent graphs, containing nodes for committed transactions
of the Isolation Theorem [14]: plus a node for the executing transaction.
Mixing Theorem: If a history is mixing-correct,
each transaction is provided the guarantees that 6. Conclusions
pertain to its level.

The above theorem holds at the level of a history and is in- This paper has presented new, precise specifications of
dependent of how synchronization is implemented 1 . Note the ANSI-SQL isolation levels. Unlike previous propos-
that the guarantees provided to each level are with respect als, the new definitions are implementation-independent and
allow a wide range of concurrency control techniques, in-
1 As stated in [14], this does not imply that a PL-3 transaction observes
cluding locking and optimism. Furthermore, our definitions
a consistent state since lower level transactions may have modified the
database inconsistently; if we want a PL-3 transaction to observe a consis-
handle predicates in a correct and flexible manner at all iso-
tent state, lower level transactions must update the database consistently lation levels. Thus, they meet the goals of the ANSI-SQL
even if they observe an inconsistent state. standard.

11
 The paper also specified the behavior of systems that [8] H. Berenson, P. Bernstein, J. Gray, J. Melton, E. O’Neil, and
allow mixing of levels: users are allowed to choose the level P. O’Neil. A Critique of ANSI SQL Isolation Levels. In
for each transaction they run, and the system guarantees that Proc. of SIGMOD, San Jose, CA, May 1995.
each transaction is provided with the constraints of its own [9] P. A. Bernstein, V. Hadzilacos, and N. Goodman. Concur-
rency Control and Recovery in Database Systems. Addison
level, even when some transactions are running at lower
Wesley, 1987.
levels.
[10] P. Chrysanthis and K. Ramamritham. Synthesis of Extended
Our approach is applicable to other levels in addition Transaction Models using ACTA. ACM TODS, 19(3), Sept.
to the ones discussed in the paper. We have developed 1994.
implementation-independent specifications of commercial [11] C. J. Date. An Introduction to Database Systems. Addison-
isolation levels such as Snapshot Isolation and Cursor Sta- Wesley, Fifth edition, 1990.
bility, and we have defined a new level called PL-2+; the [12] J. Gray, P. Helland, P. O’Neil, and D. Shasha. The Dangers of
details can be found in [1]. PL-2+ is the the weakest level Replication and a Solution. In Proc. of SIGMOD, Montreal,
that guarantees consistent reads and causal consistency; it is Canada, June 1996.
[13] J. Gray, R. Lorie, G. Putzolu, and I. Traiger. Granularity of
useful in client-server systems [3, 1] and broadcast environ-
Locks and Degrees of Consistency in a Shared Database. In
ments [25].
Modeling in Data Base Management Systems. Amsterdam:
All of our definitions are implementation independent. Elsevier North-Holland, 1976.
This makes them suitable for use as an industry standard, [14] J. N. Gray and A. Reuter. Transaction Processing: Concepts
since they do not preclude clever but unconventional imple- and Techniques. Morgan Kaufmann Publishers Inc., 1993.
mentations that either exist today or may be developed in [15] R. Gruber. Optimism vs. Locking: A Study of Concurrency
the future. Instead they provide implementors with the op- Control for Client-Server Object-Oriented Databases. PhD
portunity to choose the best performing concurrency control thesis, M.I.T., Cambridge, MA, 1997.
mechanism for their environment. [16] R. Gruber, F. Kaashoek, B. Liskov, and L. Shrira. Dis-
connected Operation in the Thor Object-Oriented Database
System. In IEEE Workshop on Mobile Comp. Systems, 1994.
Acknowledgements [17] M. P. Herlihy. Apologizing Versus Asking Permission: Op-
timistic Concurrency Control for Abstract Data Types. ACM
We would like to thank Chandra Boyapati, Miguel Castro, An- TODS, 15(1), March 1990.
[18] J. J. Kistler and M. Satyanarayanan. Disconnected Operation
drew Myers, and other members of the Programming Methodology
in the Coda File System. In Proc of the ACM Symp. on
Group for their comments. We are grateful to Dimitris Liarokapis Operating Sys. Principles, Pacific Grove, CA., Oct. 1991.
and Elizabeth O’Neil for carefully reading the paper and helping us [19] H. Korth, A. Silberschatz, and S. Sudarshan. Database Sys-
improve the specifications. We would also like to thank Phil Bern- tem Concepts. McGraw Hill, 1997.
stein, Jim Gray, and David Lomet, for their helpful comments. [20] H. T. Kung and J. T. Robinson. On Optimistic Methods for
Concurrency Control. ACM TODS, 6(2), June 1981.
[21] B. Liskov, A. Adya, M. Castro, M. Day, S. Ghemawat,
References R. Gruber, U. Maheshwari, A. Myers, and L. Shrira. Safe
and Efficient Sharing of Persistent Objects in Thor. In Proc.
[1] A. Adya. Weak Consistency: A Generalized Theory and Op- of SIGMOD, Montreal, Canada, June 1996.
timistic Implementations for Distributed Transactions. PhD [22] D. Maier, J. Stein, A. Otis, and A. Purdy. Development of an
thesis, MIT, Cambridge, MA, Mar. 1999. Object-Oriented dDBMS. In Proc. of OOPSLA, Sept 1986.
[2] A. Adya, R. Gruber, B. Liskov, and U. Maheshwari. Ef- [23] P. O’Neil. The Escrow Transactional Method. ACM TODS,
ficient Optimistic Concurrency Control using Loosely Syn- 11(4), Dec. 1986.
chronized Clocks. In SIGMOD, San Jose, CA, May 1995. [24] Oracle Corporation. Concurrency Control, Transaction Iso-
[3] A. Adya and B. Liskov. Lazy Consistency Using Loosely lation and Serializability in SQL92 and Oracle7, July 1995.
Synchronized Clocks. In Proc. of ACM Principles of Dist. [25] J. Shanmugasundaram, A. Nithrakashyap, R. Sivasankaran,
Computing, Santa Barbara, CA, Aug. 1997. and K. Ramamritham. Efficient Concurrency Control for
[4] D. Agrawal, A. E. Abbadi, and A. K. Singh. Consistency Broadcast Environments. In SIGMOD, Philadelphia, PA,
and Orderability: Semantics-Based Correctness Criteria for June 1999.
Databases. ACM TODS, 18(3), Sept. 1993. [26] D. Terry et al. Managing Update Conflicts in Bayou, a
[5] D. Agrawal, A. J. Bernstein, P. Gupta, and S. Sengupta. Weakly Connected Replicated Storage System. In Proc. of
Distributed Multi-version Optimistic Concurrency Control SOSP, Copper Mountain Resort, CO, Dec. 1995.
with Reduced Rollback. Distributed Computing, 2(1), 1987.
[6] ANSI X3.135-1992, American National Standard for Infor-
mation Systems – Database Language – SQL, Nov 1992.
[7] B. R. Badrinath and K. Ramamritham. Semantics-Based
Concurrency Control: Beyond Commutativity. ACM TODS,
17(1), Mar. 1992.

12