The document provides a critique of the ANSI SQL isolation levels and proposes new definitions. It identifies ambiguities in how ANSI SQL defines isolation levels in terms of phenomena like "dirty reads" and "non-repeatable reads". The authors redefine the phenomena, introduce new phenomena like "dirty writes", and define new isolation types like Snapshot Isolation that provide better concurrency without compromising consistency. They characterize different isolation levels by the phenomena and anomalies they allow. The critique aims to establish a clearer hierarchy of isolation levels and their properties.

1. A Critique of ANSI SQL Isolation Levels
Raees Khan
A summary of the work “A Critique of ANSI SQL Isolation Levels” by Hal Berenson,
Phil Bernstein, Jim Gray, Jim Melton, Elizabeth O’Neil, and Patrick O’Neil. ACM
SIGMOD International Conference on Management of data, 1995.
Seminar on Snapshot Isolation Level
Technische Universit¨at Kaiserslautern, Summer semester 2016.
1 Abstract
ANSI SQL-92 defines Isolation Levels in terms of the three phenomena which are ”Dirty Reads”,
”Non-Repeatable Reads”, and ”Phantoms”. These three phenomena have ambiguities and fail
to characterize several isolation levels defined by ANSI SQL-92. The authors investigated and
analyzed these phenomena, which let to reintroduced definitions for ANSI SQL-92’s phenomena
(”Dirty Reads”, ”Non-Repeatable Reads”, and ”Phantoms”). They have also defined new
anomalies and phenomena. One of the important multi-version isolation types was also defined
called Snapshot Isolation.
2 Introduction
Isolation is one of the ACID (Atomicity, Consistency, Isolation, and Durability) properties in
DBMS (database management system). Lower isolation levels allow more users to access data at
same time, but the data may be uncommitted, invalid, or users can access a database state which
never existed. On the other hand, higher isolation levels allow fewer users (no concurrency)
at the same time, but the data is valid. However, choosing a higher isolation level has the
possibility that one transaction blocks another transaction. The ANSI SQL-92 standard defines
four isolation levels based on the serializability definition. They also define three prohibited
action subsequences, called phenomena. These are “Dirty Read”, “Non-repeatable Read” and
“Phantom”. The authors criticize the definition of the isolation levels and give proposals to
define the isolation levels in a more specific way. They show weaknesses in the anomaly approach
to define isolation levels, and therefore the authors define new phenomena, anomalies, and some
other isolation levels and propose to put them in an isolation hierarchy. The authors define
and focus on a multi-version isolation type, which is called Snapshot Isolation that can better
characterize isolation types.
3 ANSI SQL Isolation Levels and Locking
ANSI SQL defines isolation levels in terms of three phenomena, which are Dirty Read (P1),
Non-repeatable Read (P2), and Phantom (P3). In a history H1, when transaction T1 writes
a data item and transaction T2 reads the same data item before T1’s commit or rollback, P1
occurs. In a history H2, when T1 reads a data item and T2 writes the same data item, if T1
reads the same data item again, it will receive an updated or modified value which is different
from T1’s first read, P2 occurs. In a history H3, when T1 reads a data item that satisfies some
1

2. Table 1. ANSI SQL Isolation levels and their three original phenomena.
Possible (P), Not Possible (NP)
Isolation level P1 Dirty Read P2 Non-
repeatable Read
P3 Phantom
ANSI READ UNCOMMITTED P P P
ANSI READ COMMITTED NP P P
ANSI REPEATABLE READ NP NP P
ANOMALY SERIALIZABLE NP NP NP
search condition and T2 writes the same data item, that also satisfies T1’s search condition, and
commits, if T1 reads the same data item with the same search condition again, it will receive
an updated or modified set of values which is different from T1’s first read, P3 occurs. None of
these three phenomena occurs in serializable history.
3.1 Restating Phenomena
The ANSI SQL phenomena are ambiguous, so they might be restated. P1 is restated from the
original ANSI SQL phenomenon w1[x]. . . r2[x]. . . (a1 and a2 in either order) to w1[x]. . . r2[x]. . . ((c1
or a1) and (c2 or a2) in any order). The authors called the original ANSI SQL phenomenon
”Anomaly” A1, and the restated phenomenon ”Phenomenon” P1. A1 is a strict interpreta-
tion while P1 is a loose interpretation. They also called the original ANSI SQL phenomena
”Anomaly” A2 and A3, and the restated phenomena ”Phenomena” P2 and P3, respectively.
The restated phenomenon P2 is r1[x]...w2[x]...((c1 or a1) and (c2 or a2) in any order). The
restated phenomenon P3 is r1[P]...w2[y in P]...((c1 or a1) and (c2 or a2) any order). Table
1 shows four isolation levels and their three phenomena. The SERIALIZABLE isolation level
is not defined by ANSI SQL, but the authors added this isolation level which prevents the
three phenomena (i.e., P1, P2, P3). The authors called this isolation level as ANOMALY
SERIALIZABLE.
3.2 Locking
Almost all commercial products use lock-based isolation. Hence, it is important to characterize
ANSI SQL isolation levels in terms of locking. Therefore, J. Gray et al. [1] defined four
degrees of consistency. They tried to compare the locking levels with the ANSI SQL isolation
levels. The degree 0 consistency allows dirty reads and dirty writes, while the degrees 1, 2, and 3
correspond to Locking READ UNCOMMITTED, READ COMMITTED, and SERIALIZABLE.
There was no isolation degree matched with REPEATABLE READ, but, still, the authors
added it in order to equalize with the ANSI SQL isolation levels. The authors remarked that
Locking SERIALIZABLE (Degree 03) provides stronger isolation than Locking REPEATABLE
READ, Locking READ COMMITTED (Degree 02), and Locking READ UNCOMMITTED
(Degree 01). Locking REPEATABLE READ provides stronger isolation than Locking READ
COMMITTED and Locking READ UNCOMMITTED. Locking READ COMMITTED provides
stronger isolation than Locking READ UNCOMMITTED.
4 Analyzing ANSI SQL Isolation Levels and Locking
Locking isolation for all of its levels provides stronger isolation than the ANSI SQL isolation lev-
els, because Locking READ UNCOMMITTED provides long duration write locking to prevent
phenomenon named Dirty Writes P0. The original ANSI SQL do not define P0.
2

3. Dirty Write is defined as follows: A transaction T1 updates a data item and transaction
T2 updates the same data item before T1 performs a ROLLBACK or COMMIT. If T1 or
T2 perform a ROLLBACK, it is unclear what would be the correct data value. Dirty Write
could be stated as P0: w1[x]...w2[x]...((c1 or a1) and (c2 or a2) in any order). Hence, ANSI
SQL isolation levels should be modified to P0. There were unplanned weaknesses in the strict
interpretations such as A1, A2, A3, and the correct interpretations are the loose interpretations
P1, P2, P3. The ANSI SQL isolation levels P0, P1, P2, P3 are the redefinitions of the Locking
isolation levels. The ANSI SQL phenomena are still incomplete. In summary, new phenomena
and anomalies are required to define. Some new phenomena and anomalies are defined in the
next two sections.
5 Cursor Stability
Cursor Stability is used to avoid lost updates. This occurs when T1 reads a data item, then
T2 updates the same data item based on its previous read, then T1 updates the same data
item based on its previous read and commits. It is expressed as P4: r1[x]. . . w2[x]. . . w1[x]. . . c1.
Cursor Stability provides stronger isolation than READ COMMITTED isolation, because it
reads action from the current cursor (read cursor rc) and requiring that a lock is held on the
current item of the cursor. The lock is held until the cursor moves or is closed. When the
cursor moves or is closed then the lock is released. The fetching transaction can update the
row, in that case, a write lock (wc) is held until the transaction commits. Therefore, rc1[x] with
a subsequent operation wc1[x] prevents an interruption of w2[x]; that’s why P4 is renamed as
P4C. It is expressed as P4C: rc1[x]. . . w2[x]. . . w1[x]. . . c1.
6 Snapshot Isolation
The snapshot isolation is defined as follows: When a transaction starts, it gets assigned a
Start-Timestamp, by reading the data item that was lastly committed with respect to time.
In snapshot isolation, a transaction cannot be blocked by another transaction while reading
data items. When T1 wants to commit, it gets assigned a Commit-Timestamp. This Commit-
Timestamp should be larger than any existing Start-Timestamp or Commit-Timestamp. When
a transaction T1 commits a data item, then the same data item will be visible to all other
transactions. Transaction T1 will only be committed, if no other transaction (e.g., T2) with its
Commit-Timestamp has written data that T1 also writes; otherwise, T1 will be aborted. The
authors named this feature as First-Committer-Wins which also avoids lost updates (P4) as
we discussed earlier. Snapshot isolation is a multi-version method (MV). The only reason that
Snapshot isolation is placed in the isolation hierarchy is that Snapshot isolation can be mapped
to a single-valued history.
Snapshot isolation failed to maintain some constraints. In a history H1, some constraint
may fail. For example, H1: r1[x=50] r1[y=50] r2[x=50] r2[y=50] w1[y=-40] w2[x=-40] c1 c2.
This constraint violation is known as inconsistent analysis. The authors defined two anomalies
which violate constraint rules. These are Read Skew (A5A) and Write Skew (A5B). In A5A, a
transaction T1 reads, data item x, then transaction T2 updates x and y, and commits. When
transaction T1 again reads data item y, it faces an inconsistent state. For example, A5A:
r1[x]...w2[x]...w2[y]...c2...r1[y]...(c1 or a1). In A5B, let us say there is a consistency constraint
between x and y. A transaction T1 reads data items x and y. Then transaction T2 reads x and
y, writes y and commits. After this operation, transaction T1 writes y. In this case, the given
constraint is violated between x and y. For example, A5B: r1[x]...r2[y]...w1[y]...w2[x]...(c1 and
c2 occur).
Snapshot Isolation could give a good result when short update transactions conflict min-
imally and long-running transactions are likely to be read only. Besides that, it has a clear
3

4. Table 2. Isolation types characterized by possible anomalies allowed.
Possible (P), Sometimes Possible (SP), Not Possible (NP)
Isolation level P0
Dirty
Write
P1
Dirty
Read
P4C
Cursor
Lost
Update
P4
Lost
Up-
date
P2
Fuzzy
Read
P3
Phan-
tom
A5A
Read
Skew
A5B
Write
Skew
READ UNCOMMIT-
TED == Degree 1
NP P P P P P P P
READ COMMITTED
== Degree 2
NP NP P P P P P P
Cursor Stability NP NP NP SP SP P P SP
REPEATABLE READ NP NP NP NP NP P NP NP
Snapshot NP NP NP NP NP SP NP P
ANSI SQL SERIALIZ-
ABLE == Degree 3
NP NP NP NP NP NP NP NP
advantage of concurrency for read-only transactions. Other commercial products use some
features of the Snapshot Isolation. For example, Oracle Read Consistency isolation.
7 Summary
There were problems in the ANSI SQL definition of isolation levels. P0 was not precluded.
P3 was restated. Isolation levels falling between Repeatable Read and Serializable have been
characterized by some new phenomena and anomalies. Isolation levels which were newly defined
are Cursor Stability and Snapshot Isolation. New phenomena and anomalies defined are the
P0, P4, P4C, A5A, A5B. Snapshot Isolation provides higher concurrency, avoids the lost update
anomaly, also avoids some phantom anomalies, never blocks read-only transactions and readers
do not block updates.
Table 1 contained the original ANSI SQL isolation levels, while Table 2 characterizes the
proposed isolation levels as a consequence of the critical analysis of the original ANSI SQL
isolation levels.
References
[1] J. Gray, R. Lorie, G. Putzolu and, I. Traiger Granularity of Locks and Degrees of Consistency
in a Shared Data Base,” in Readings in Database Systems. Readings in database systems,
1988.
4