1. A Critique of ANSI SQL
Isolation Levels
Presenter: Raees Khan
Date: 26.07.2016
(raees.afridi@yahoo.com)
2. Contents
1. Introduction
2. Isolation Definitions
i. Serializability Concept
ii. ANSI SQL Isolation Levels
iii. Locking
3. Analyzing ANSI SQL Isolation Levels
4. Other Isolation Types
i. Cursor Stability
ii. Snapshot Isolation
iii. Other Multi-Version Systems
5. Conclusion
26-07-2016 www.uni-kl.de 2
8. Shorthand notations
26-07-2016 www.uni-kl.de 8
Operation Description
r1[x] read of x by transaction 1
w2[x] write by transaction 2 on data item x
r1[p] transaction 1 reading a set of records satisfying predicate p
w2[p] transaction 2 writing a set of records satisfying predicate p
a1 transaction 1 abort
c2 transaction 2 commit
9. 2.1 Serializability Concepts
• Definitions
• History: A history models the interleaved execution of a set of transactions as
a linear ordering of their actions, such as Reads and Writes (i.e., inserts,
updates, and deletes) of specific data items
• H1: r1[x] w1[x] c1 r2[y] w2[y] c2
26-07-2016 www.uni-kl.de 9
10. 2.1 Serializability Concepts (Cont.)
• Definitions (Cont.)
• Serializable: A history that is equivalent (in its outcome) to a serial history
• H2: r1[x] r2[y] w1[x] w2[y] c1 c2
26-07-2016 www.uni-kl.de 10
11. 2.1 Serializability Concepts (Cont.)
• Definitions (Cont.)
• Conflicting actions: Two actions are said to be in conflict if
• The actions belong to different transactions.
• The actions access the same object (read or write).
• At least one of the actions is a write operation.
• H3: r1[x] w2[x] : conflicting actions
• H4: r1[x] r2[x] : no conflicting actions
26-07-2016 www.uni-kl.de 11
13. 2.1 Serializability Concepts (Cont.)
• Definitions (Cont.)
• Conflicting equivalence: The histories H5 and H7 are said to be conflict-
equivalent if following two conditions are satisfied
• Both histories H5 and H7 involve the same set of transactions (including ordering of
actions within each transaction).
• Both schedules have same set of conflicting operations.
• Example:
• H5: r1[x] w2[x] r1[y] w2[y]
• H6: w1[x] w1[y] r2[x] r2[y]
• H7: r1[x] r1[y] w2[x] w2[y]
26-07-2016 www.uni-kl.de 13
15. 2.1 Serializability Concepts (Cont.)
• Definitions (Cont.)
• Conflict-serializable: A history H5 is said to be conflict-serializable when the
history H5 is conflict-equivalent to one or more serial histories, e.g. H7
• Example 01:
• H7 is a serial history
• H5 is conflict equivalent to H7
26-07-2016 www.uni-kl.de 15
35. 3. Analyzing ANSI SQL Isolation Levels (Cont.)
• Hence, ANSI SQL isolation should be modified to require P0 for all
isolation levels
• Loose interpretation of three ANSI phenomena is required
• Recall strict interpretation
• A1: w1[x]...r2[x]...(a1 and c2 in either order) (Dirty Read)
• A2: r1[x]...w2[x]...c2...r1[x]...c1 (Fuzzy or Non-Repeatable Read)
• A3: r1[P]...w2[y in P]...c2....r1[P]...c1 (Phantom)
26-07-2016 www.uni-kl.de 35
36. 3. Analyzing ANSI SQL Isolation Levels (Cont.)
• Strict interpretation: A1, A2, A3 have weaknesses.
• Correct interpretations are the loose ones.
26-07-2016 www.uni-kl.de 36
37. 3. Analyzing ANSI SQL Isolation Levels (Cont.)
• ANSI SQL isolation phenomena are incomplete
• Number of anomalies still can arise
• New phenomena must be defined
• P3 must be restated
• Restating P3
• ANSI SQL P3 only prohibits inserts to a predicate
• P3: r1[P]...w2[y in P]...(c1 or a1) prohibits any write to a predicate
• e.g. insert, update, delete
26-07-2016 www.uni-kl.de 37
44. 4. Other Isolation Types
• Cursor Stability isolation level extends Read Committed locking
behavior
• By adding new read operation for Fetch from a cursor, read cursor and
requiring that a lock be held on the current item of the cursor
• Fetching transaction can update the row and, in that case, a write lock will
be held on the row until the transaction commits, even after the cursor
moves on with a subsequent Fetch
26-07-2016 www.uni-kl.de 44
4.1 : Cursor Stability < less isolated
> more isolated
46. 4. Other Isolation Types
• High concurrency
• Non-serializable history
• Read-only transactions never abort
• Never block other transactions
• First-committer-wins rule
• Prevents lost updates
• Type of multi-version concurrency control
26-07-2016 www.uni-kl.de 46
4.2 : Snapshot Isolation (Cont.)
50. 4. Other Isolation Types
26-07-2016 www.uni-kl.de 50
• 4.2 : Snapshot Isolation (Cont.)
• Snapshot Isolation (SI) is a multi-version method
• At any time, each data item might have multiple versions
• Reads by a transaction must choose the appropriate version
• Example : Transferring $40 from x to y
• H1: r1[x=50]w1[x=10]r2[x=10]r2[y=50]c2 r1[y=50]w1[y=90]c1
51. 4. Other Isolation Types
26-07-2016 www.uni-kl.de 51
• 4.2 : Snapshot Isolation (Cont.)
• Under Snapshot Isolation, the same sequence of actions would lead to the
multi-valued history
• H1.SI: r1[x0=50] w1[x1=10] r2[x0=50] r2[y0=50] c2 r1[y0=50] w1[y1=90] c1
• H1.SI has the data flows of a serializable execution
52. 4. Other Isolation Types
26-07-2016 www.uni-kl.de 52
• 4.2 : Snapshot Isolation (Cont.)
• Snapshot Isolation MV histories can be mapped to single-valued histories
• H1.SI.SV: r1[x=50] r1[y=50] r2[x=50] r2[y=50] c2 w1[x=10] w1[y=90] c1
• And thus, we put Snapshot Isolation in Isolation Hierarchy
53. 4. Other Isolation Types
26-07-2016 www.uni-kl.de 53
• 4.2 : Snapshot Isolation (Cont.)
• Snapshot Isolation is non-serializable
• Transaction’s Reads come at one instant and the Writes at another
• H5: r1[x=50] r1[y=50] r2[x=50] r2[y=50] w1[y=-40] w2[x=-40] c1 c2
• Hence, constraint fails to hold in H5
54. 4. Other Isolation Types
26-07-2016 www.uni-kl.de 54
• 4.2 : Snapshot Isolation (Cont.)
• A5 (Data Item Constraint Violation)
• suppose C() is a database constraint between two data items x and y in the database
• two anomalies arising from constraint violation
• A5A Read Skew
• A5B Write Skew
57. 4. Other Isolation Types
26-07-2016 www.uni-kl.de 57
• 4.2 : Snapshot Isolation (Cont.)
• Analysis and placing of Snapshot Isolation in Isolation Hierarchy
• Fuzzy Reads (P2) is a degenerate form of Read Skew where x=y
• A transaction reads two different but related items (e.g., referential integrity)
• Write skew anomaly arises in history H5 where (x + y) should be positive
• A5A & A5B could not arise in histories where P2 is prevented.
• both A5A & A5B have T2 write data item that is previously read by an uncommitted T1
• hence, phenomena A5A and A5B are only useful for distinguishing isolation levels that are
below REPEATABLE READ in strength.
58. 4. Other Isolation Types
26-07-2016 www.uni-kl.de 58
• 4.2 : Snapshot Isolation (Cont.)
• Analysis and placing of Snapshot Isolation in Isolation Hierarchy (Cont.)
• Snapshot Isolation is stronger than READ COMMITTED
• In Snapshot Isolation, first-committer-wins precludes P0 (dirty writes)
• Timestamp mechanism prevents P1 (dirty reads)
• So Snapshot Isolation is not weaker than READ COMMITTED.
• A5A (Read Skew) is possible under READ COMMITTED
• A5A (Read Skew) is not possible under the Snapshot Isolation timestamp mechanism.
59. 4. Other Isolation Types
26-07-2016 www.uni-kl.de 59
• 4.2 : Snapshot Isolation (Cont.)
• Analysis and placing of Snapshot Isolation in Isolation Hierarchy (Cont.)
• Is Snapshot Isolation stronger or weaker than REPEATABLE READ?
• Difficult to picture how Snapshot Isolation histories can disobey phenomenon P2 in the
single-valued interpretation
• Anomaly A2 cannot occur, since a transaction under Snapshot Isolation will read the same
value of a data item
• Write Skew (A5B) can occur in a Snapshot Isolation history (e.g., H5)
• In the Single Valued history interpretation we've been reasoning about, forbidding P2 also
precludes A5B
• Therefore, Snapshot Isolation admits history anomalies that REPEATABLE READ does not
60. 4. Other Isolation Types
26-07-2016 www.uni-kl.de 60
• 4.2 : Snapshot Isolation (Cont.)
• Analysis and placing of Snapshot Isolation in Isolation Hierarchy (Cont.)
• Is Snapshot Isolation stronger or weaker than REPEATABLE READ? (Cont.)
• Snapshot Isolation cannot experience the A3 anomaly
• A transaction rereading a predicate after an update by another will always see the same
old set of data items
• REPEATABLE READ isolation level can experience A3 anomalies
• Result
• Snapshot Isolation histories prohibit histories with anomaly A3, but allow A5B
• REPEATABLE READ prohibits histories with anomaly A5B, but allow A3
• Snapshot Isolation is stronger than REPEATABLE READ
• REPEATABLE READ is stronger than Snapshot Isolation
61. 4. Other Isolation Types
26-07-2016 www.uni-kl.de 61
• 4.2 : Snapshot Isolation (Cont.)
• Analysis and placing of Snapshot Isolation in Isolation Hierarchy (Cont.)
• Does Snapshot Isolation preclude P3? No
• First-Committer-Wins could not preclude P3
• In any equivalent serial history, the phenomenon P3 would arise under this scenario
62. 4. Other Isolation Types
26-07-2016 www.uni-kl.de 62
• 4.2 : Snapshot Isolation (Cont.)
• Analysis and placing of Snapshot Isolation in Isolation Hierarchy (Cont.)
63. 4. Other Isolation Types
26-07-2016 www.uni-kl.de 63
• 4.2 : Snapshot Isolation (Cont.)
• Analysis and placing of Snapshot Isolation in Isolation Hierarchy (Cont.)
• Snapshot Isolation is stronger than ANOMALY SERIALIZABLE
• Snapshot Isolation has no phantoms (strict interpretation)
• Each transaction never sees the updates of concurrent transactions
• hence Snapshot Isolation histories preclude anomalies A1, A2 and A3
64. 4. Other Isolation Types
26-07-2016 www.uni-kl.de 64
• 4.2 : Snapshot Isolation (Cont.)
• Analysis and placing of Snapshot Isolation in Isolation Hierarchy (Cont.)
• Consequences of Snapshot Isolation
• concurrency advantage for read-only transactions
• benefits for update transactions is still debated
• not good for long-running update transactions
• For good result: short update transactions conflict minimally and long-running
transactions are likely to be read only
65. 4. Other Isolation Types
• Some commercial products
• Maintain versions of objects
• Restrict Snapshot Isolation to read-only transactions
• E.g. SQL-92
• Other commercial products
• Allow Snapshot Isolation to update transactions
• Don’t provide first-committer-wins protection
• E.g. Oracle Read Consistency isolation
26-07-2016 www.uni-kl.de 65
4.3 : Other Multi-Version Systems
67. 5. Conclusion
• Problems in ANSI SQL definition of isolation levels
• Dirty Writes (P0) are not precluded
• Cleaning up ANSI Isolation levels
• Need to define new phenomena
• P3 was restated
• ANSI Repeatable Read
• Intended to exclude all anomalies except phantom
• Repeatable reads do not give repeatable results
• Locking definition gives repeatable results
26-07-2016 www.uni-kl.de 67
68. 5. Conclusion
• Characterizing Isolation levels
• Isolation levels, falling between Repeatable Read and Serializable levels, have been
characterized with some new phenomena and anomalies
• Isolation levels: Cursor Stability, Snapshot Isolation
• Phenomena: P0, P4, P4C
• Anomalies: A5A, A5B
• Snapshot Isolation
• Avoids lost update anomaly
• Some phantom anomalies
• Never blocks read-only transactions
• Readers do not block updates
26-07-2016 www.uni-kl.de 68
72. Authors of original paper
• Hal Berenson Microsoft Corp. haroldb@microsoft.com
• Phil Bernstein Microsoft Corp. philbe@microsoft.com
• Jim Gray Microsoft Corp. gray@microsoft.com
• Jim Melton Sybase Corp. jim.melton@sybase.com
• Elizabeth O’Neil UMass/Boston eoneil@cs.umb.edu
• Patrick O'Neil UMass/Boston poneil@cs.umb.edu
• June 1995
• Technical Report, MSR-TR-95-51, Microsoft Research
• Advanced Technology Division
• Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
26-07-2016 www.uni-kl.de 72
