Conflict Serializability

Introduction to Database Systems

• A schedule is conflict serializable if it can be
CSE 414
transformed into a serial schedule by a series of
swappings of adjacent non-conflicting actions

Lecture 24: • Every conflict-serializable schedule is serializable

Implementation of Transactions • The converse is not true (why?)

CSE 414 - Spring 2018 1 CSE 414 - Spring 2018 2

Testing for Conflict-Serializability Example 2

Precedence graph:
• A node for each transaction Ti,
r2(A); r1(B); w2(A); r2(B); r3(A); w1(B); w3(A); w2(B)
• An edge from Ti to Tj whenever an action in Ti
conflicts with, and comes before an action in Tj
B
• The schedule is conflict-serializable iff the A
precedence graph is acyclic 1 2 3
B

This schedule is NOT conflict-serializable

CSE 414 - Spring 2018 3 CSE 414 - Spring 2018 4

More Notations A Non-Serializable Schedule

T1 T2
READ(A)
A := A+100
WRITE(A)
Li(A) = transaction Ti acquires lock for element A READ(A)
A := A*2
Ui(A) = transaction Ti releases lock for element A WRITE(A)
READ(B)
B := B*2
WRITE(B)
READ(B)
B := B+100
WRITE(B)
CSE 414 - Spring 2018 5 CSE 414 - Spring 2018 6

1
 Example But…
T1 T2
T1 T2
L1(A); READ(A)
L1(A); READ(A)
A := A+100
A := A+100
WRITE(A); U1(A); L1(B)
WRITE(A); U1(A);
L2(A); READ(A)
L2(A); READ(A)
A := A*2
A := A*2
WRITE(A); U2(A);
WRITE(A); U2(A);
L2(B); BLOCKED…
L2(B); READ(B)
READ(B)
B := B*2
B := B+100
WRITE(B); U2(B);
WRITE(B); U1(B);
L1(B); READ(B)
…GRANTED; READ(B)
B := B+100
B := B*2
WRITE(B); U1(B);
WRITE(B); U2(B);
CSE 414 - Springschedule
Scheduler has ensured a conflict-serializable 2018 7 Locks did not enforce conflict-serializability !!! What’s wrong ? 8

Two Phase Locking (2PL) Example: 2PL transactions

T1 T2
L1(A); L1(B); READ(A)
A := A+100
WRITE(A); U1(A)
The 2PL rule: L2(A); READ(A)
A := A*2
In every transaction, all lock requests WRITE(A);
L2(B); BLOCKED…
must precede all unlock requests READ(B)
B := B+100
WRITE(B); U1(B);
…GRANTED; READ(B)
B := B*2
Now it is conflict-serializable
WRITE(B); U2(A); U2(B);
CSE 414 - Spring 2018 9 CSE 414 - Spring 2018 10

Two Phase Locking (2PL) Two Phase Locking (2PL)

Theorem: 2PL ensures conflict serializability Theorem: 2PL ensures conflict serializability
Proof. Suppose not: then
there exists a cycle
in the precedence graph.
C
T1 T3

A B
T2
11

2
 Two Phase Locking (2PL) Two Phase Locking (2PL)
Theorem: 2PL ensures conflict serializability Theorem: 2PL ensures conflict serializability
Proof. Suppose not: then Then there is the Proof. Suppose not: then Then there is the
there exists a cycle following temporal there exists a cycle following temporal
in the precedence graph. cycle in the schedule: in the precedence graph. cycle in the schedule:
U1(A)àL2(A) why?
C C
T1 T3 T1 T3
U1(A) happened
A B A B strictly before L2(A)
T2 T2
13 14

Two Phase Locking (2PL) Two Phase Locking (2PL)

Theorem: 2PL ensures conflict serializability Theorem: 2PL ensures conflict serializability
Proof. Suppose not: then Then there is the Proof. Suppose not: then Then there is the
there exists a cycle following temporal there exists a cycle following temporal
in the precedence graph. cycle in the schedule: in the precedence graph. cycle in the schedule:
U1(A)àL2(A) U1(A)àL2(A)
C C
T1 T3 L2(A)àU2(B) why? T1 T3 L2(A)àU2(B) why?

A B L2(A) happened A B
T2 strictly before U1(A) T2
15 16

Two Phase Locking (2PL) Two Phase Locking (2PL)

Theorem: 2PL ensures conflict serializability Theorem: 2PL ensures conflict serializability
Proof. Suppose not: then Then there is the Proof. Suppose not: then Then there is the
there exists a cycle following temporal there exists a cycle following temporal
in the precedence graph. cycle in the schedule: in the precedence graph. cycle in the schedule:
U1(A)àL2(A) U1(A)àL2(A)
C C
T1 T3 L2(A)àU2(B) T1 T3 L2(A)àU2(B)
U2(B)àL3(B) why? U2(B)àL3(B)
A B A B
T2 T2
......etc.....
17 18

3
 A New Problem:
Two Phase Locking (2PL) Non-recoverable Schedule
T1 T2
L1(A); L1(B); READ(A)
Theorem: 2PL ensures conflict serializability A :=A+100
WRITE(A); U1(A)
Proof. Suppose not: then Then there is the L2(A); READ(A)
A := A*2
there exists a cycle following temporal WRITE(A);
in the precedence graph. cycle in the schedule: L2(B); BLOCKED…
READ(B)
U1(A)àL2(A)
C B :=B+100
T1 T3 L2(A)àU2(B) WRITE(B); U1(B);
…GRANTED; READ(B)
U2(B)àL3(B)
A B B := B*2
L3(B)àU3(C) WRITE(B); U2(A); U2(B);
T2
U3(C)àL1(C) Cycle in time: Commit
Rollback
L1(C)àU1(A)
Contradiction
19 CSE 414 - Spring 2018 20

A New Problem: A New Problem:

Non-recoverable Schedule Non-recoverable Schedule
T1 T2 T1 T2
L1(A); L1(B); READ(A) L1(A); L1(B); READ(A)
A :=A+100 A :=A+100
WRITE(A); U1(A) WRITE(A); U1(A)
L2(A); READ(A) L2(A); READ(A)
A := A*2 A := A*2
WRITE(A); WRITE(A); Dirty reads of
L2(B); BLOCKED… L2(B); BLOCKED… A, B lead to
READ(B) READ(B) incorrect writes.
B :=B+100 B :=B+100
WRITE(B); U1(B); WRITE(B); U1(B);
…GRANTED; READ(B) …GRANTED; READ(B)
B := B*2 B := B*2
WRITE(B); U2(A); U2(B); WRITE(B); U2(A); U2(B);
Elements A, B written Commit Elements A, B written Commit
Rollback by T1 are restored Rollback by T1 are restored
to their original CSE
value.
414 - Spring 2018 21 to their original CSE
value.
414 - Spring 2018 22

A New Problem:
Non-recoverable Schedule
Strict 2PL
T1 T2
T1 T2 L1(A); READ(A)
L1(A); L1(B); READ(A) A :=A+100
A :=A+100 WRITE(A);
WRITE(A); U1(A) L2(A); BLOCKED…
L2(A); READ(A) L1(B); READ(B)
A := A*2 B :=B+100
WRITE(A); Dirty reads of WRITE(B);
L2(B); BLOCKED… A, B lead to
READ(B) Rollback & U1(A);U1(B);
incorrect writes.
B :=B+100 …GRANTED; READ(A)
WRITE(B); U1(B); A := A*2
…GRANTED; READ(B) WRITE(A);
B := B*2 L2(B); READ(B)
WRITE(B); U2(A); U2(B); B := B*2
Elements A, B written Commit WRITE(B);
Rollback by T1 are restored Commit & U2(A); U2(B);
to their original CSE
value.
414 - Spring 2018
Can no longer 23
undo! 24

4
 Strict 2PL Another problem: Deadlocks
• T1: R(A), W(B)
The Strict 2PL rule: • T2: R(B), W(A)

All locks are held until commit/abort: • T1 holds the lock on A, waits for B
All unlocks are done together with commit/abort. • T2 holds the lock on B, waits for A

With strict 2PL, we will get schedules that

are both conflict-serializable and recoverable This is a deadlock!
CSE 414 - Spring 2018 25 CSE 414 - Spring 2018 26

Another problem: Deadlocks A “Solution”: Lock Modes

To detect a deadlocks, search for a cycle in the • S = shared lock (for READ)
waits-for graph: • X = exclusive lock (for WRITE)
• T1 waits for a lock held by T2;
• T2 waits for a lock held by T3;
• ... Lock compatibility matrix:

• Tn waits for a lock held by T1 None S X

None
S
Relatively expensive: check periodically, if deadlock is
found, then abort one transaction. X
need to continuously re-check for deadlocks
27 CSE 414 - Spring 2018 28

A “Solution”: Lock Modes Lock Granularity

• S = shared lock (for READ) • Fine granularity locking (e.g., tuples)
• X = exclusive lock (for WRITE) – High concurrency
– High overhead in managing locks
– E.g., SQL Server

Lock compatibility matrix: • Coarse grain locking (e.g., tables, entire database)
– Many false conflicts
None S X
– Less overhead in managing locks
None ✔ ✔ ✔ – E.g., SQL Lite
S ✔ ✔ ✖
X ✔ ✖ ✖ • Solution: lock escalation changes granularity as needed

CSE 414 - Spring 2018 29 CSE 414 - Spring 2018 30

5
 Lock Performance Phantom Problem
Throughput (TPS)

To avoid, use
admission control • So far we have assumed the database to be a
static collection of elements (=tuples)

• If tuples are inserted/deleted then the phantom

thrashing problem appears

Why ?

TPS =
Transactions # Active Transactions
per second
CSE 414 - Spring 2018 31 CSE 414 - Spring 2018 32

Suppose there are two blue products, A1, A2: Suppose there are two blue products, A1, A2:
Phantom Problem Phantom Problem
T1 T2 T1 T2
SELECT * SELECT *
FROM Product FROM Product
WHERE color=‘blue’ WHERE color=‘blue’
INSERT INTO Product(name, color) INSERT INTO Product(name, color)
VALUES (‘A3’,’blue’) VALUES (‘A3’,’blue’)
SELECT * SELECT *
FROM Product FROM Product
WHERE color=‘blue’ WHERE color=‘blue’

R1(A1);R1(A2);W2(A3);R1(A1);R1(A2);R1(A3)
Is this schedule serializable ?
CSE 414 - Spring 2018 33 CSE 414 - Spring 2018 34

Suppose there are two blue products, A1, A2:

Phantom Problem Phantom Problem
T1 T2
• A “phantom” is a tuple that is
SELECT *
invisible during part of a transaction execution but
FROM Product
WHERE color=‘blue’ not invisible during the entire execution
INSERT INTO Product(name, color)
VALUES (‘A3’,’blue’) • In our example:
SELECT * – T1: reads list of products
FROM Product – T2: inserts a new product
WHERE color=‘blue’
– T1: re-reads: a new product appears !

R1(A1);R1(A2);W2(A3);R1(A1);R1(A2);R1(A3)

W2(A3);R1(A1);R1(A2);R1(A1);R1(A2);R1(A3) CSE 414 - Spring 2018 36

6
 Dealing With Phantoms Summary of Serializability
• Lock the entire table • Serializable schedule = equivalent to a serial
• Lock the index entry for ‘blue’ schedule
– If index is available • (strict) 2PL guarantees conflict serializability
• Or use predicate locks – What is the difference?
– A lock on an arbitrary predicate • Static database:
– Conflict serializability implies serializability
• Dynamic database:
– This no longer holds
Dealing with phantoms is expensive !
CSE 414 - Spring 2018 37 CSE 414 - Spring 2018 38

Isolation Levels in SQL 1. Isolation Level: Dirty Reads

1. “Dirty reads” • “Long duration” WRITE locks
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
– Strict 2PL
2. “Committed reads” • No READ locks
SET TRANSACTION ISOLATION LEVEL READ COMMITTED – Read-only transactions are never delayed

3. “Repeatable reads”
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ

4. Serializable transactions ACID

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
Possible problems: dirty and inconsistent reads
CSE 414 - Spring 2018 39 CSE 414 - Spring 2018 40

2. Isolation Level: Read Committed 3. Isolation Level: Repeatable Read

• “Long duration” WRITE locks • “Long duration” WRITE locks

– Strict 2PL – Strict 2PL
• “Short duration” READ locks • “Long duration” READ locks
– Only acquire lock while reading (not 2PL) – Strict 2PL

Why ?
Unrepeatable reads:
When reading same element twice, This is not serializable yet !!!
may get two different values
CSE 414 - Spring 2018 41 CSE 414 - Spring 2018 42

7
 4. Isolation Level Serializable
• “Long duration” WRITE locks
– Strict 2PL
• “Long duration” READ locks
– Strict 2PL
• Predicate locking
– To deal with phantoms
CSE 414 - Spring 2018
Beware!
In commercial DBMSs:
• Default level is often NOT serializable
• Default level differs between DBMSs
• Some engines support subset of levels!
• Serializable may not be exactly ACID
– Locking ensures isolation, not atomicity
• Also, some DBMSs do NOT use locking and
different isolation levels can lead to different pbs
• Bottom line: RTFM for your DBMS!
43 CSE 414 - Spring 2018 44