Database

Systems
Optimistic
Concurrency Control
15-445/645 FALL 2024 PROF. ANDY PAVLO

15-445/645 FALL 2024 PROF. ANDY PAVLO

 2

LAST CLASS
We discussed concurrency control protocols for
generating conflict serializable schedules without
needing to know what queries a txn will execute.

The two-phase locking (2PL) protocol requires txns

to acquire locks on database objects before they are
allowed to access them.

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 3

OBSERVATION
If you assume that conflicts between txns are rare
and that most txns are short-lived, then forcing
txns to acquire locks adds unnecessary overhead.

A better concurrency control protocol could be one

that is optimized for the no-conflict case…

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 4

T/O CONCURRENCY CONTROL

Use timestamps to determine the serializability
order of txns.

If TS(Ti) < TS(Tj), then the DBMS must ensure

that the execution schedule is equivalent to the
serial schedule where Ti appears before Tj.

Each database object (e.g., tuple) will include

additional fields to keep track of timestamp(s) of the
txns that last accessed/modified them.

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 5

TIMESTAMP ALLOCATION
Each txn Ti is assigned a unique fixed timestamp
that is monotonically increasing.
→ Let TS(Ti) be the timestamp allocated to txn Ti.
→ Different schemes assign timestamps at different times
during the txn.

Multiple implementation strategies:

→ System/Wall Clock.
→ Logical Counter.
→ Hybrid.

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 6

TODAY’S AGENDA
Optimistic Concurrency Control
Phantom Reads
Isolation Levels
DB Flash Talk: Weaviate

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 OPTIMISTIC CONCURRENCY CONTROL (OCC)
6

T/O protocol where DBMS creates a

private workspace for each txn.
→ Any object read is copied into workspace.
→ Modifications are applied to workspace.

When a txn commits, the DBMS

compares workspace write set to see
whether it conflicts with other txns.

If there are no conflicts, the write set

is installed into the “global” database.
5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 8

OCC PHASES
Phase #1 – Read
→ Track the read/write sets of txns and store their writes in a
private workspace.
→ DBMS copies every tuple that the txn accesses from the
shared database to its workspace ensure repeatable reads.

Phase #2 – Validation
→ Assign the txn a unique timestamp (TS) and then check
whether it conflicts with other txns.

Phase #3 – Write
→ If validation succeeds, set the write timestamp (W-TS) to all
modified objects in private workspace and install them into
5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

the global database. Otherwise abort txn.
 9

OCC EXAMPLE
Schedule
T1 T2
Database
BEGIN Object Value W-TS
READ A 123 0
R(A) BEGIN
- - -
READ
TIME

R(A)
VALIDATE
WRITE
COMMIT
W(A)
R(A)
VALIDATE
WRITE
COMMIT

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 10

OCC EXAMPLE
Schedule
T1 T2
Database
BEGIN Object Value W-TS
READ A 123 0
R(A) BEGIN
- - -
READ
TIME

R(A)
VALIDATE
WRITE
COMMIT
W(A)
R(A)
VALIDATE
WRITE
COMMIT

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 11

OCC EXAMPLE
Schedule
T1 T2
Database
BEGIN Object Value W-TS
READ A 123 0
R(A) BEGIN
- - -
READ
TIME

R(A)
VALIDATE
WRITE T1 Workspace
COMMIT
Object Value W-TS
W(A)
- - -
R(A)
VALIDATE - - -
WRITE
COMMIT

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 12

OCC EXAMPLE
Schedule
T1 T2
Database
BEGIN Object Value W-TS
READ A 123 0
R(A) BEGIN
- - -
READ
TIME

R(A)
VALIDATE
WRITE T1 Workspace
COMMIT
Object Value W-TS
W(A)
R(A) A- 123
- -0
VALIDATE - - -
WRITE
COMMIT

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 13

OCC EXAMPLE
Schedule
T1 T2
Database
BEGIN Object Value W-TS
READ A 123 0
R(A) BEGIN
- - -
READ
TIME

R(A)
VALIDATE
WRITE T1 Workspace T2 Workspace
COMMIT
Object Value W-TS Object Value W-TS
W(A)
R(A) A- 123
- -0 - - -
VALIDATE - - - - - -
WRITE
COMMIT

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 14

OCC EXAMPLE
Schedule
T1 T2
Database
BEGIN Object Value W-TS
READ A 123 0
R(A) BEGIN
- - -
READ
TIME

R(A)
VALIDATE
WRITE T1 Workspace T2 Workspace
COMMIT
Object Value W-TS Object Value W-TS
W(A)
A- 123
- -0 -A 123
- -0
R(A)
VALIDATE - - - - - -
WRITE
COMMIT

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 15

OCC EXAMPLE
Schedule
T1 T2
Database
BEGIN Object Value W-TS
READ A 123 0
R(A) BEGIN
- - -
READ
TS(T2 )=1
TIME

R(A)
VALIDATE
WRITE T1 Workspace T2 Workspace
COMMIT
Object Value W-TS Object Value W-TS
W(A)
A- 123
- -0 -A 123
- -0
R(A)
VALIDATE - - - - - -
WRITE
COMMIT

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 16

OCC EXAMPLE
Schedule
T1 T2
Database
BEGIN Object Value W-TS
READ A 123 0
R(A) BEGIN
- - -
READ
TS(T2 )=1
TIME

R(A)
VALIDATE
WRITE T1 Workspace
COMMIT
Object Value W-TS
W(A)
R(A) A- 123
- -0
VALIDATE - - -
WRITE
COMMIT

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 17

OCC EXAMPLE
Schedule
T1 T2
Database
BEGIN Object Value W-TS
READ A 123 0
R(A) BEGIN
- - -
READ
TS(T2 )=1
TIME

R(A)
VALIDATE
WRITE T1 Workspace
COMMIT
Object Value W-TS
W(A)
R(A) A- 456
-456
123 -1∞
0
VALIDATE - - -
WRITE
COMMIT

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 18

OCC EXAMPLE
Schedule
T1 T2
Database
BEGIN Object Value W-TS
READ A 123 0
R(A) BEGIN
- - -
READ
TS(T2 )=1
TIME

R(A)
VALIDATE
WRITE T1 Workspace
COMMIT
Object Value W-TS
W(A)
R(A) A- 456
-456
123 -1∞
0
VALIDATE - - -
WRITE
COMMIT

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 19

OCC EXAMPLE
Schedule
T1 T2
Database
BEGIN Object Value W-TS
READ A 123 0
R(A) BEGIN
- - -
READ
TS(T2 )=1
TIME

R(A)
VALIDATE
WRITE T1 Workspace
COMMIT
Object Value W-TS
W(A)
R(A) TS(T1)=2 A- 456
-456
123 -1∞
0
VALIDATE - - -
WRITE
COMMIT

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 20

OCC EXAMPLE
Schedule
T1 T2
Database
BEGIN Object Value W-TS
READ A 456
123 02
R(A) BEGIN
- - -
READ
TS(T2 )=1
TIME

R(A)
VALIDATE
WRITE T1 Workspace
COMMIT
Object Value W-TS
W(A)
R(A) TS(T1)=2 A- 456
-456
123 -1∞
02
VALIDATE - - -
WRITE
COMMIT

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 21

OCC: READ PHASE

Track the read/write sets of txns and store their
writes in a private workspace.

The DBMS copies every tuple that the txn accesses

from the shared database to its workspace ensure
repeatable reads.
→ We can ignore for now what happens if a txn reads/writes
tuples via indexes.

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 22

OCC: VALIDATION PHASE

When txn Ti invokes COMMIT, the DBMS checks if
it conflicts with other txns.
→ Original OCC algorithm uses serial validation.
→ Parallel validation requires each txn check read/write sets
of other txns trying to validate at the same time.

DBMS needs to guarantee only serializable

schedules are permitted.
→ Approach #1: Backward Validation
→ Approach #2: Forward Validation

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 13

OCC: VALIDATION PHASE

Forward Validation: Check whether the
committing txn intersects its read/write sets with
any active txns that have not yet committed.

Backward Validation: Check whether the

committing txn intersects its read/write sets with
those of any txns that have already committed.

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 24

OCC: FORWARD VALIDATION

Each txn's timestamp is assigned at the beginning of
the validation phase.

Check the timestamp ordering of the committing

txn with all other active txns.

If TS(T1) < TS(T2), then one of the following three

conditions must hold…

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 25

OCC: FORWARD VALIDATION CASE #1

Schedule
T1 T2
If (T1 < T2), check if T1 completes
BEGIN
its Write phase before T2 begins
READ its Read phase.
⋮
VALIDATE
No conflict as all T1's actions
TIME

WRITE
COMMIT BEGIN
READ
happen before T2's.
⋮ → This just means that there is serial
VALIDATE ordering.
WRITE
COMMIT

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 26

OCC: FORWARD VALIDATION CASE #2

If (T1 < T2), check if T1 completes its Write phase
before T2 starts its Write phase and T1 does not
modify to any object read by T2.
→ WriteSet(T1) ∩ ReadSet(T2) = Ø

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 27

OCC: FORWARD VALIDATION CASE #2

Schedule
T1 T2
Database
BEGIN Object Value W-TS
READ A 123 0
R(A)
- - -
W(A) BEGIN
TIME

READ
R(A)
VALIDATE T1 Workspace
VALIDATE
Object Value W-TS
WRITE
- - -
COMMIT
- - -

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 28

OCC: FORWARD VALIDATION CASE #2

Schedule
T1 T2
Database
BEGIN Object Value W-TS
READ A 123 0
R(A)
- - -
W(A) BEGIN
TIME

READ
R(A)
VALIDATE T1 Workspace
VALIDATE
Object Value W-TS
WRITE
-A 123
- -0
COMMIT
- - -

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 29

OCC: FORWARD VALIDATION CASE #2

Schedule
T1 T2
Database
BEGIN Object Value W-TS
READ A 123 0
R(A)
- - -
W(A) BEGIN
TIME

READ
R(A)
VALIDATE T1 Workspace
VALIDATE
Object Value W-TS
WRITE
-A 123
-456 -0
∞
COMMIT
- - -

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 30

OCC: FORWARD VALIDATION CASE #2

Schedule
T1 T2
Database
BEGIN Object Value W-TS
READ A 123 0
R(A)
- - -
W(A) BEGIN
TIME

READ
R(A)
VALIDATE T1 Workspace T2 Workspace
VALIDATE
Object Value W-TS Object Value W-TS
WRITE
-A 123
-456 -0
∞ - - -
COMMIT
- - - - - -

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 31

OCC: FORWARD VALIDATION CASE #2

Schedule
T1 T2
Database
BEGIN Object Value W-TS
READ A 123 0
R(A)
- - -
W(A) BEGIN
TIME

READ
R(A)
VALIDATE T1 Workspace T2 Workspace
VALIDATE
Object Value W-TS Object Value W-TS
WRITE
-A 123
-456 -0
∞ -A -123 -0
COMMIT
- - - - - -

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 32

OCC: FORWARD VALIDATION CASE #2

Schedule
T1 T2
Database
BEGIN Object Value W-TS
READ A 123 0
R(A)
- - -
W(A) BEGIN
TIME

READ
R(A)
VALIDATE T1 Workspace T2 Workspace
VALIDATE
Object Value W-TS Object Value W-TS
WRITE
-A 123
-456 -0
∞ -A -123 -0
T1 must abort even though T2
COMMIT
- - - - - -
did not modify the database.

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 33

OCC: FORWARD VALIDATION CASE #2

Schedule
T1 T2
Database
BEGIN Object Value W-TS
READ A 123 0
R(A) BEGIN
- - -
W(A) READ
TIME

R(A)
VALIDATE
VALIDATE T1 Workspace
WRITE
Object Value W-TS
COMMIT WRITE
- - -
COMMIT
- - -

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 34

OCC: FORWARD VALIDATION CASE #2

Schedule
T1 T2
Database
BEGIN Object Value W-TS
READ A 123 0
R(A) BEGIN
- - -
W(A) READ
TIME

R(A)
VALIDATE
VALIDATE T1 Workspace
WRITE
Object Value W-TS
COMMIT WRITE
-A 123
- -0
COMMIT
- - -

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 35

OCC: FORWARD VALIDATION CASE #2

Schedule
T1 T2
Database
BEGIN Object Value W-TS
READ A 123 0
R(A) BEGIN
- - -
W(A) READ
TIME

R(A)
VALIDATE
VALIDATE T1 Workspace T2 Workspace
WRITE
Object Value W-TS Object Value W-TS
COMMIT WRITE
-A 123
- -0 - - -
COMMIT
- - - - - -

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 36

OCC: FORWARD VALIDATION CASE #2

Schedule
T1 T2
Database
BEGIN Object Value W-TS
READ A 123 0
R(A) BEGIN
- - -
W(A) READ
TIME

R(A)
VALIDATE
VALIDATE T1 Workspace T2 Workspace
WRITE
Object Value W-TS Object Value W-TS
COMMIT WRITE
-A 123
-456 -0
∞ - - -
COMMIT
- - - - - -

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 37

OCC: FORWARD VALIDATION CASE #2

Schedule
T1 T2
Database
BEGIN Object Value W-TS
READ A 123 0
R(A) BEGIN
- - -
W(A) READ
TIME

R(A)
VALIDATE
VALIDATE T1 Workspace T2 Workspace
WRITE
Object Value W-TS Object Value W-TS
COMMIT WRITE
-A 123
-456 -0
∞ -A -123 -0
COMMIT
- - - - - -

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 38

OCC: FORWARD VALIDATION CASE #2

Schedule
T1 T2
Database
BEGIN Object Value W-TS
READ Safe to commit because
A T2 123 0
R(A) BEGIN
W(A) READ finishes before-T1 - -
TIME

R(A)
VALIDATE
VALIDATE T1 Workspace T2 Workspace
WRITE
Object Value W-TS Object Value W-TS
COMMIT WRITE
-A 123
-456 -0
∞ -A -123 -0
COMMIT
- - - - - -

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 39

OCC: FORWARD VALIDATION CASE #2

Schedule
T1 T2
Database
BEGIN Object Value W-TS
READ A 123 0
R(A) BEGIN
- - -
W(A) READ
TIME

R(A)
VALIDATE
VALIDATE T1 Workspace T2 Workspace
WRITE
Object Value W-TS Object Value W-TS
COMMIT WRITE
-A 123
-456 -0
∞ -A -123 -0
Safe to commit T1 because T2
COMMIT
- - - - - -
commits logically before T1

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 40

OCC: FORWARD VALIDATION CASE #3

If (T1 < T2), check if T1 completes its Read phase
before T2 completes its Read phase and T1 does not
modify any object either read or written by T2:
→ WriteSet(T1) ∩ ReadSet(T2) = Ø
→ WriteSet(T1) ∩ WriteSet(T2) = Ø

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 41

OCC: FORWARD VALIDATION CASE #3

Schedule
T1 T2
Database
BEGIN Object Value W-TS
READ A 123 0
R(A) BEGIN
B XYZ 0
W(A) READ
TIME

R(B)
VALIDATE
WRITE T1 Workspace T2 Workspace
COMMIT R(A)
Object Value W-TS Object Value W-TS
VALIDATE
-A -123
456 -0∞ -B -XYZ 0-
WRITE
COMMIT - - - - - -

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 42

OCC: FORWARD VALIDATION CASE #3

Schedule
T1 T2
Database
BEGIN Object Value W-TS
READ A 123 0
R(A) BEGIN
B XYZ 0
W(A) READ
TS(T1 )=1
TIME

R(B)
VALIDATE
WRITE T1 Workspace T2 Workspace
COMMIT R(A)
Object Value W-TS Object Value W-TS
VALIDATE
-A -123
456 -0∞ -B -XYZ 0-
WRITE
COMMIT - - - - - -

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 43

OCC: FORWARD VALIDATION CASE #3

Schedule
T1 T2
Database
BEGIN Object Value W-TS
READ A 123
456 01
R(A) BEGIN
B XYZ 0
W(A) READ
TS(T1 )=1
TIME

R(B)
VALIDATE
WRITE T1 Workspace T2 Workspace
COMMIT R(A)
Object Value W-TS Object Value W-TS
VALIDATE
-A -123
456 -0∞
1 -B -XYZ 0-
WRITE
COMMIT - - - - - -

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 44

OCC: FORWARD VALIDATION CASE #3

Schedule
T1 T2
Database
BEGIN Object Value W-TS
READ A 123
456 01
R(A) BEGIN
B XYZ 0
W(A) READ
TIME

R(B)
VALIDATE
WRITE T2 Workspace
COMMIT R(A)
Object Value W-TS
VALIDATE
-B -XYZ 0-
WRITE
COMMIT -A -456 1-

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 45

OCC: FORWARD VALIDATION CASE #3

Schedule
T1 T2
Database
BEGIN Object Value W-TS
READ A 123
456 01
R(A) BEGIN
B XYZ 0
W(A) READ
TIME

R(B)
VALIDATE
WRITE TS(T2 )=2 T2 Workspace
COMMIT R(A)
Object Value W-TS
VALIDATE
-B -XYZ 0-
WRITE
COMMIT -A -456 1-

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 46

OCC: FORWARD VALIDATION

Check whether the committing txn intersects its
read/write sets with any active txns that have not
yet committed.

Txn #1

COMMIT
Txn #2

COMMIT
Txn #3

COMMIT
TIME
5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 47

OCC: FORWARD VALIDATION

Check whether the committing txn intersects its
read/write sets with any active txns that have not
yet committed.

Txn #1

COMMIT
Validation Scope
Txn #2

COMMIT
Txn #3

COMMIT
TIME
5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 48

OCC: BACKWARD VALIDATION

Check whether the committing txn intersects its
read/write sets with those of any txns that have
already committed.

Txn #1

COMMIT
Txn #2

COMMIT
Txn #3

COMMIT
TIME
5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 49

OCC: BACKWARD VALIDATION

Check whether the committing txn intersects its
read/write sets with those of any txns that have
already committed.
Validation Scope
Txn #1

COMMIT
Txn #2

COMMIT
Txn #3

COMMIT
TIME
5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 50

OCC: WRITE PHASE

Propagate changes in the txn’s write set to database
to make them visible to other txns.
Serial Commits:
→ Use a global latch to limit a single txn to be in the
Validation/Write phases at a time.

Parallel Commits:
→ Use fine-grained write latches to support parallel
Validation/Write phases.
→ Txns acquire latches in a sequential key order to avoid
deadlocks.

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 51

OCC: OBSERVATIONS
OCC works well when the # of conflicts is low:
→ All txns are read-only (ideal).
→ Txns access disjoint subsets of data.

But OCC has its own problems:

→ High overhead for copying data locally.
→ Validation/Write phase bottlenecks.
→ Aborts are more wasteful than in 2PL because they only
occur after a txn has already executed.

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 52

OBSERVATION
We have only dealt with transactions that read and
update existing objects in the database.

But now if txns perform insertions, updates, and

deletions, we have new problems…

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 53

THE PHANTOM PROBLEM

Schedule
T1 T2 CREATE TABLE people (
BEGIN BEGIN id SERIAL,
SELECT COUNT(*) AS cnt
name VARCHAR,
FROM people status VARCHAR
WHERE status='lit' );
TIME

cnt=99 INSERT INTO people

VALUES
(101,'Andy','lit');
COMMIT
SELECT COUNT(*) AS cnt
FROM people
WHERE status='lit'

COMMIT

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 54

THE PHANTOM PROBLEM

Schedule
T1 T2 CREATE TABLE people (
BEGIN BEGIN id SERIAL,
SELECT COUNT(*) AS cnt
name VARCHAR,
FROM people status VARCHAR
WHERE status='lit' );
TIME

cnt=99 INSERT INTO people

VALUES
(101,'Andy','lit');
COMMIT
SELECT COUNT(*) AS cnt
FROM people
WHERE status='lit'

COMMIT

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 55

THE PHANTOM PROBLEM

Schedule
T1 T2 CREATE TABLE people (
BEGIN BEGIN id SERIAL,
SELECT COUNT(*) AS cnt
name VARCHAR,
FROM people status VARCHAR
WHERE status='lit' );
TIME

cnt=99 INSERT INTO people

VALUES
(101,'Andy','lit');
COMMIT
SELECT COUNT(*) AS cnt
FROM people
WHERE status='lit'

cnt=100
COMMIT

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 56

THE PHANTOM PROBLEM

Schedule
T1 T2 CREATE TABLE people (
BEGIN BEGIN id SERIAL,
SELECT COUNT(*) AS cnt
name VARCHAR,
FROM people status VARCHAR
WHERE status='lit' );
TIME

cnt=99 INSERT INTO people

VALUES
(101,'Andy','lit');
COMMIT
SELECT COUNT(*) AS cnt
FROM people
WHERE status='lit'

cnt=100
COMMIT

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 57

OOPS?
How did this happen?
→ Because T1 locked only existing records and not ones that
other txns are adding to the database!

Conflict serializability on reads and writes of

individual items guarantees serializability only if
the set of objects is fixed.

This is known as a phantom read.

phantom rea

→ A txn scans a range more than once and another txn

inserts/removes tuples that fall within that range in
between the scans.
5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 58

SOLUTIONS TO THE PHANTOM PROBLEM

Approach #1: Re-Execute Scans Rare
→ Run queries again at commit to see whether they produce a
different result to identify missed changes.

Approach #2: Predicate Locking Very Rare

→ Logically determine the overlap of predicates before
queries start running.

Approach #3: Index Locking Common

→ Use keys in indexes to protect ranges.

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 59

RE-EXECUTE SCANS
The DBMS tracks the WHERE clause for all queries
that the txn executes.
→ Retain the scan set for every range query in a txn.

Upon commit, re-execute just the scan portion of

each query and check whether it generates the same
result.
→ Example: Run the scan for an UPDATE query but do not
modify matching tuples.

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 60

PREDICATE LOCKING
Proposed locking scheme from System R.
→ Shared lock on the predicate in a WHERE clause of a SELECT
query.
→ Exclusive lock on the predicate in a WHERE clause of any
UPDATE, INSERT, or DELETE query.

This is difficult to implement efficiently. Some

systems approximate it via precision locking.

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 61

PREDICATE LOCKING
SELECT COUNT(*) AS cnt
FROM people INSERT INTO people VALUES
WHERE status='lit' (101, 'Andy', 'lit')

Records in Table "people"

status='lit'
name='Andy' ∧
status='lit'

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 63

INDEX LOCKING SCHEMES

Key-Value Locks
Gap Locks
Key-Range Locks
Hierarchical Locking

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 64

KEY-VALUE LOCKS
Locks that cover a single key-value in an index.
Need “virtual keys” for non-existent values.

B+Tree Leaf Node

Key
[14, 14]

10 12 14 16

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 65

GAP LOCKS
Each txn acquires a key-value lock on the single key
that it wants to access. Then get a gap lock on the
next key gap.

B+Tree Leaf Node

10 {Gap} 12 {Gap} 14 {Gap} 16

Gap
(14, 16)

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 67

KEY-RANGE LOCKS
Locks that cover a key value and the gap to the next
key value in a single index.
→ Need “virtual keys” for artificial values (infinity)

B+Tree Leaf Node

10 {Gap} 12 {Gap} 14 {Gap} 16

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 68

KEY-RANGE LOCKS
Locks that cover a key value and the gap to the next
key value in a single index.
→ Need “virtual keys” for artificial values (infinity)

B+Tree Leaf Node

Next Key [14, 16)

10 {Gap} 12 {Gap} 14 {Gap} 16

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 69

KEY-RANGE LOCKS
Locks that cover a key value and the gap to the next
key value in a single index.
→ Need “virtual keys” for artificial values (infinity)

B+Tree Leaf Node

10 {Gap} 12 {Gap} 14 {Gap} 16

Prior Key (12, 14]

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 70

HIERARCHICAL LOCKING
Allow for a txn to hold wider key-range locks with
different locking modes.
→ Reduces the number of visits to lock manager.

IX
B+Tree Leaf Node

10 {Gap} 12 {Gap} 14 {Gap} 16

[10, 16)

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 71

HIERARCHICAL LOCKING
Allow for a txn to hold wider key-range locks with
different locking modes.
→ Reduces the number of visits to lock manager.

IX
B+Tree Leaf Node
X [14, 16)

10 {Gap} 12 {Gap} 14 {Gap} 16

[10, 16)

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 72

HIERARCHICAL LOCKING
Allow for a txn to hold wider key-range locks with
different locking modes.
→ Reduces the number of visits to lock manager.

IX
B+Tree Leaf Node
X [12, 12] X [14, 16)
IX
10 {Gap} 12 {Gap} 14 {Gap} 16
[10, 16)

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 73

LOCKING WITHOUT AN INDEX

Choice #1: Acquire locks on every page in the table
to prevent a record’s status attribute from being
changed.

Choice #2: Take a single lock for the entire table to

prevent records being modified.

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 74

WEAKER LEVELS OF ISOLATION

Serializability is useful because it allows
programmers to ignore concurrency issues.

But enforcing it may allow too little concurrency

and limit performance.

We may want to use a weaker level of consistency

to improve scalability.

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 75

ISOLATION LEVELS
Controls the extent that a txn is exposed to the
actions of other concurrent txns.

Provides for greater concurrency at the cost of

exposing txns to uncommitted changes:
→ Dirty Reads
→ Unrepeatable Reads
→ Lost Updates
→ Phantom Reads

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 76

ISOLATION LEVELS
SERIALIZABLE: No phantoms, all reads repeatable,
Isolation (High→Low)

no dirty reads.

REPEATABLE READS: Phantoms may happen.

READ COMMITTED: Phantoms, unrepeatable reads,

and lost updates may happen.

READ UNCOMMITTED: All anomalies may happen.

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 77

ISOLATION LEVELS
Dirty Unrepeatable Lost
Read Read Updates Phantom

SERIALIZABLE No No No No
REPEATABLE No No No Maybe
READ

READ COMMITTED No Maybe Maybe Maybe

READ Maybe Maybe Maybe Maybe

UNCOMMITTED

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 78

ISOLATION LEVELS
SERIALIZABLE: Strong Strict 2PL with phantom
protection (e.g., index locks).

REPEATABLE READS: Same as above, but without

phantom protection.

READ COMMITTED: Same as above, but S locks are

released immediately.

READ UNCOMMITTED: Same as above but allows dirty

reads (no S locks).
5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 79

SQL-92 ISOLATION LEVELS

The application can set a txn’s
isolation level before it executes any SET TRANSACTION ISOLATION LEVEL
queries in that txn. <isolation-level>;

Not all DBMS support all isolation BEGIN TRANSACTION ISOLATION LEVEL
<isolation-level>;
levels in all execution scenarios
→ Replicated Environments
The default depends on
implementation…

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 80

ISOLATION LEVELS
Default Maximum
Actian Ingres SERIALIZABLE SERIALIZABLE
IBM DB2 CURSOR STABILITY SERIALIZABLE
CockroachDB SERIALIZABLE SERIALIZABLE
Google Spanner STRICT SERIALIZABLE STRICT SERIALIZABLE
MSFT SQL Server READ COMMITTED SERIALIZABLE
MySQL REPEATABLE READS SERIALIZABLE
Oracle READ COMMITTED SNAPSHOT ISOLATION
PostgreSQL READ COMMITTED SERIALIZABLE
SAP HANA READ COMMITTED SERIALIZABLE
VoltDB SERIALIZABLE SERIALIZABLE
YugaByte SNAPSHOT ISOLATION SERIALIZABLE
5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 81

STRICT SERIALIZABLE

SERIALIZABLE

REPEATABLE READS SNAPSHOT ISOLATION

CURSOR STABILITY

READ COMMITTED

5-445/645 (Fall 2024)

READ UNCOMMITTED
15-445/645 (Fall 2024)
 82

DATABASE ADMIN SURVEY

What isolation level do transactions execute at on
this DBMS?
None Few Most All
30 26
22
# of Responses

20
12 12 12 11 11
10 10 10
10 8
6
8
4 5 5
2 2 3 3 2
1 1 0
0 Read Read Committed Cursor Stability Repeatable Read Snapshot Isolation Serializable
Uncommitted

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 84

CONCLUSION
Every concurrency control protocol can be broken
down into the basic concepts that have been
described in the last two lectures.
→ Pessimistic: Locking
→ Optimistic: Timestamps

There is no one protocol that is always better than

all others…

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)

 87

NEXT CLASS
Multi-Version Concurrency Control

5-445/645 (Fall 2024)

15-445/645 (Fall 2024)