A New Basis for the SQL Isolation Level Standard

Atul Adya: Microsoft Research

Barbara Liskov: LCS, MIT

Patrick O’ Neil: Univ. Of Mass., Boston

2

Degree Condition

Degree 1 (Read Uncommitted) No dirty writes

Degree 2 (Read Committed) Degree 1 + No dirty reads

Degree 3 (Serializability) Degree 2 + No fuzzy reads

ANSI Degrees of Isolation

• Trade-off consistency for performance• Serializability Disallow all “bad” situations• Implementation-independent

3

ANSI Definitions: Ambiguous

• “Flexible” Interpretation: allows bad histories

• “Locking” Interpretation: suggested approach– “Disguised” versions of locking

– Multi-object constraints not observed as violated

[BBG+ 95]: Berenson, Bernstein, Gray, Melton, O’Neil, O’Neil: SIGMOD 95[BBG+ 95]: Berenson, Bernstein, Gray, Melton, O’Neil, O’Neil: SIGMOD 95

x1 10

x1: 10 y0: 50

y1 90T1

T2

x0 = 50y0 = 50

4

Need Locking-Independent Defns

Current Interpretation• Overly restrictive: no concurrent conflicting opns

Disallows optimistic and multi-version mechanismsNon-locking implementations:

– Desirable in certain environments, e.g., mobile systems

– Used in commercial products: [Oracle], [Gemstone]

• Predicate-based operations: not handled properly

5

Our Approach

• Specifications for ANSI levels (PL-1, PL-2, PL-3)– Implementation-independent and unambiguous– Compatible with existing ANSI definitions– Flexible guarantees for predicate-based operations

• Definitions for existing commercial levels, e.g., Cursor Stability, Snapshot Isolation [BBG+95, Oracle]

• Definitions for new levels weaker than serializabilityE.g., Weakest level that ensures consistent reads

6

First Observation

Problem: Isolation provided as transactions run

Idea: Provide separate guarantees for committed and running transactions

Degrees for running transactions

Degrees for committed transactions

–

|||

LockingInterpretation

1

32

1 2 3

––

7

Second Observation

Problem: Multi-object constraints captured using conditions on single object histories

Idea: Capture using invariants on complete read and write sets of transactions

Use serialization graphs

8

Direct Serialization Graphx1 10

x2: 20 y0: 50

y1 90T1

T3

x0 = 50y0 = 50 x2 20T2

T1 T2 T3

WW WR

RW

DSG(H)

History H

Committed transactions only

9

New Definitions: PL-3 and PL-2

Serializability (PL-3):• Capture essence of “no dirty reads”, i.e.,

ensure each committed transaction has onlyread modifications of committed transactions– No Aborted Reads

– No Intermediate Reads

– No Circular Information Flow: Disallow cyclesconsisting of only W W or W R edges

• Disallow all cycles

PL-2

10

Applying Definitions at PL-3Bad history disallowed (unlike “flexible”)

Good history allowed (unlike “locking”)

WR RW

x1 10

x1: 10 y0: 50

y1 90

x1 10

x1: 10 y1: 90

y1 90 WR

T1

T2

T1

T2

T1

T1

T2

T2x0 = 50y0 = 50

11

Handling Predicates

Approach: Add conflict edges for predicate opns

T1: SELECT * FROM Emp WHERE Dept = Sales

T2: UPDATE Dept = Legal FROM Emp WHERE Dept = Mktg

T1 and T2 do not conflict

T3: DELETE FROM Emp WHERE Location = Boston

T3 changes the set of tuples matched by T1’s read, i.e., T3

overwrites T1’s predicate-based readT1 T3

R W

12

Summary• Our specifications can form the basis for fixing the

ANSI standard– Implementation-independent

– Handle predicates correctly

– Backwards compatible and intuitive

• Specifications for existing commercial levels, e.g., Cursor Stability, Snapshot Isolation

• New useful isolation levels between degrees 2 and 3

http://www.pmg.lcs.mit.edu/~adyahttp://research.microsoft.com/~adya