Isolation in Relational

Databases
Chapter 24

1
 What’s Different About Locking in
Relational Databases?
• In the simple databases we have been studying,
accesses are made to named items (e.g. r(x)).
– x can be locked
• In relational databases, accesses are made to
items that satisfy a predicate (for example, a
SELECT statement)
– What should we lock?
– What is a conflict?

2
 Conflicts in Relational Databases

Audit: NewAccount:
SELECT SUM (balance) INSERT INTO Accounts
FROM Accounts VALUES (‘123’,‘Mary’,100);
WHERE name = ‘Mary’;

SELECT totbal UPDATE Depositors

FROM Depositors SET totbal = totbal + 100
WHERE name = ‘Mary’ WHERE name = ‘Mary’

• Operations on Accounts and Depositors conflict

• Interleaved execution is not serializable

3
 What to Lock?

• Lock tables (TL):

– Execution is serializable but ...
– Performance suffers because lock granularity is
coarse

• Lock rows (RL):

– Performance improves because lock granularity
is fine but ...
– Execution is not serializable

4
 Problem with Row Locking

• Audit
(1) Locks and reads Mary’s rows in Accounts

• NewAccount
(2) Inserts and locks new row t, in Accounts
(3) Locks and updates Mary’s row in Depositors
time (4) Commits and releases all locks

• Audit
(5) Locks and reads Mary’s row in Depositors

5
 Row Locking (RL)

• The two SELECT statements in Audit see

inconsistent data
– The second sees the effect of NewAccount;
the first does not

• Problem: Audit’s SELECT and NewAccount’s

INSERT do not commute, but the row locks
held by Audit did not delay the INSERT
– The inserted row is referred to as a phantom

6
 Phantoms in RL

• Phantoms occur when row locking is used and

– T1 SELECTs, UPDATEs, or DELETEs using a pred. P
– T2 creates a row (using INSERT or UPDATE) satisf. P

• Example:
T1: UPDATE Table T2: INSERT INTO Table
SET Attr = …. VALUES ( … satisfies P…)
WHERE P

7
 Phantoms in RL

• INSERT and UPDATE cause phantoms

with row locking.

• Question: Why does DELETE not cause a

similar problem with row locking?
– Answer: A row that has been read cannot be
deleted because it is locked

8
 Predicate Locking (PL)
• TL prevents phantoms; RL does not
• Predicate locking also prevents phantoms
– A predicate describes a set of rows, some are in a
table and some are not; e.g. name = ‘Mary’
• A subset of the rows satisfying name = ‘Mary’ are in Accounts
– Every SQL statement has an associated predicate
– When executing a statement, acquire a (read or write)
lock on the associated predicate
– Two predicate locks conflict if one is a write and there
exists a row (not necessarily in the table) that is
contained in both

9
 Phantoms

rows in R satisfying P
(rows that can be locked)

rows satisfying
rows in predicate P
table R

rows satisfying P
all rows that can that do not exist in R
possibly be in table R

10
 Preventing Phantoms With PLs

Audit: NewAccount:
SELECT SUM (balance) INSERT INTO Accounts
FROM Accounts VALUES (‘123’,‘Mary’,100)
WHERE name = ‘Mary’

• Audit gets read lock on predicate name=‘Mary’

• NewAccount requests write lock on predicate
(acctnum=‘123’  name=‘Mary’  bal=100)
• Request denied since predicates overlap

11
 Conflicts And Predicate Locks
• Example 1:
SELECT SUM (balance) DELETE
FROM Accounts FROM Accounts
WHERE name = ‘Mary’ WHERE bal < 100
• Statements conflict since:
– Predicates overlap and one is a write
– There might be acc with bal < 100 and name = ‘Mary’
– Locking is conservative: there might be no rows in
Accounts satisfying both predicates
– No phantom involved in this (DELETE) case
12
 Conflicts And Predicate Locks
• Example 2:

SELECT SUM (balance) DELETE

FROM Accounts FROM Accounts
WHERE name = ‘Mary’ WHERE name = ‘John’
• Statements commute since:
– Predicates are disjoint.
– There can be no rows (in or not in Accounts) that satisfy
both predicates
– No phantom involved in this (DELETE) case

13
 Serializability in Relational DB
• Table locking
– prevents phantoms and
– produces serializable schedules, but
– negatively impacts performance

• Row locking
– does not prevent phantoms and
– can produce nonserializable schedules
– Performance ok

14
 Serializability in Relational DB
• Predicate locking
– prevents phantoms and
– produces serializable schedules, but is
– too complex to implement

• What’s an implementor to do?

– Later we discuss more efficient locking methods
(granular locking and index locking) that prevent
phantoms and produce serializable schedules

15
 Isolation Levels
• SQL defines several isolation levels weaker than
SERIALIZABLE that allow non-serializable
schedules and hence allow more concurrency

Serializable schedules delays

s serializable s
conc. control
s

s

s weaker s
conc. control
Schedules allowed
at a weaker isolation level fewer delays
16
 Isolation Levels

• Schedules produced by CC operating at isolation

levels lower than SERIALIZABLE:
– Might be correct for some applications
– We give examples later.

• SQL standard defines isolation levels in terms of

certain anomalies they do or do not allow

17
 Anomaly

• We have already talked about some anomalies

– Dirty Read
– Dirty Write
– Lost Update
– Phantom

• Now we discuss one more

– Non-Repeatable Read

18
 Anomaly: Non-Repeatable Read

T1 T2
SELECT SUM (balance)
FROM Accounts
WHERE name = ‘Mary’
UPDATE Accounts
SET balance = 1.05 * balance
WHERE name = ‘Mary’
SELECT SUM (balance) does not introduce a
FROM Accounts phantom into predicate
WHERE name = ‘Mary’ name=‘Mary’

19
Non-Repeatable Reads and Phantoms

• With a phantom, execution of same SELECT

twice yields different sets of rows
– The second returns at least one row not
returned by the first

• With a non-repeatable read, execution of same

SELECT twice yields the same set of rows, but
attribute values might be different

20
 SQL Isolation Levels

• READ UNCOMMITTED – dirty reads, non-

repeatable reads, and phantoms allowed
• READ COMMITTED - dirty reads not allowed, but
non-repeatable reads and phantoms allowed
• REPEATABLE READ – dirty reads, non-repeatable
reads not allowed, but phantoms allowed
• SERIALIZABLE – dirty reads, non-repeatable
reads, and phantoms not allowed; all schedules
must be serializable

21
 SQL Isolation Levels

• Defining isolation levels in terms of anomalies

leads to an ambiguous specification:
– At what levels are dirty writes allowed?
– Are there other anomalies that are not accounted for?

22
 Statement Isolation
• In addition, statement execution must be isolated
– DBMS might be executing several SQL statements (from
different transactions) concurrently
– The execution of statement involves the execution of a
program implementing that statement’s query plan
• This might be a complex program

– While the execution of transactions T1 and T2 might not

be isolated, the execution of each statement within T1
must be isolated with respect to the execution of each
statement within T2.

23
 Locking Implementation of SQL
Isolation Levels
• SQL standard does not say how to implement levels
• Locking implementation is based on:
– Entities locked: rows, predicates, …
– Lock modes: read & write
– Lock duration:
• Short: locks acquired in order to execute a statement
are released when statement completes
• Long: locks acquired in order to execute a statement are
held until transaction completes
• Medium: something in between (we give example later)

24
 Locking Implementation of SQL
Isolation Levels
• Write locks are handled identically at all
isolation levels:
– Long-duration predicate write locks are associated
with UPDATE, DELETE, and INSERT statements
• This rules out dirty writes
– In practice, predicate locks are implemented with
table locks or by acquiring locks on an index as
well as the data
• We discuss index locking later

25
 Locking Implementation of SQL
Isolation Levels
• Read locks handled differently at each level:
– READ UNCOMMITTED: no read locks
• Hence a transaction can read a write-locked item!
• Allows dirty reads, non-repeatable reads, and phantoms

– READ COMMITTED: short-duration read locks on

rows returned by SELECT
• Prevents dirty reads, but non-repeatable reads and
phantoms are possible

26
 Locking Implementation
– REPEATABLE READ: long-duration read locks on
rows returned by SELECT
• Prevents dirty and non-repeatable reads, but
phantoms are possible

– SERIALIZABLE: long-duration read lock on

predicate specified in WHERE clause
• Prevents dirty reads, non-repeatable reads, and
phantoms and …
• Guarantees serializable schedules

27
 Bad Things Can Happen

• At every isolation level lower than

SERIALIZABLE, bad things can happen

• Schedules can be
– Non-serializable
– Specifications of transactions might not be met

28
Some Problems at READ UNCOMMITTED
• Since no read locks are obtained, T2 can read a
row t, write locked by T1
T1: w(t) abort T2 uses an aborted
T2: r(t) w(t) commit value to update db

T2 uses an intermediate
T1: w(t) w(t) commit
value to update db
T2: r(t) w(t) commit
T2 does not see a
T1: w(t) w(t) commit committed snapshot
T2: r(t) r(t) commit
• Some DBMSs allow only read-only transactions
to be executed at this level
29
Some Problems at READ COMMITTED

• Non-repeatable reads:
T1: r(t) r(t) commit
T2: w(t) commit

• Lost updates:

T1: r(t) w(t) commit

T2 : r(t) w(t) commit

30
 Problems at REPEATABLE READ

• Phantoms:

Audit: r(pred) r(t ) commit

NewAccount: insert(t) update(t ) commit

– t satisfies pred
– A constraint relates rows satisfying pred and t

31
Implications of Locking Implementation
• Transactions can be assigned to different isolation
levels and can run concurrently.
– Since all write locks are long-duration predicate
locks and SERIALIZABLE transactions have
long-duration predicate read locks, SERIALIZABLE
transactions are serialized with respect to all writes.
• A SERIALIZABLE transaction either sees the entire
effect of another transaction or no effect.
– A transaction at a lower level does not see the
anomalies prohibited at that level.

32
Implications of Locking Implementation

• Even though all transactions are designed to

be consistent,
– Transactions executed at lower isolation levels
can see anomalies that can cause them to write
inconsistent data to the database
– Transactions executed at any isolation levels can
see that inconsistent data and as a result return
inconsistent data to user or store additional
inconsistent data in database

33
 CURSOR STABILITY

• A commonly implemented isolation level

(not in SQL standard) deals with cursor access
• An extension of READ COMMITTED:
– Long-duration write locks on predicates
– Short-duration read locks on rows
– Additional locks for handling cursors

34
 Cursors at READ COMMITTED
• Access by T1 through a cursor C, generally
involves OPEN followed by a sequence of FETCHs
– Each statement is atomic and isolated
– C is INSENSITIVE: rows FETCHed cannot be affected
by concurrent updates (since OPEN is isolated)
– C is not INSENSITIVE: some rows FETCHed might
have been updated by a concurrent transaction T2, and
others might not
• Furthermore, T1 might fetch a row, T2 might update the
row and commit, and then T1 might overwrite the update

35
 CURSOR STABILITY

• Read lock on row accessed through cursor is

medium-duration; held until cursor is moved
• Example
T1: fetch(t) update(t)
T2: update(t) commit
– Allowed at READ COMMITTED, hence lost
update possible
– Not allowed at CURSOR STABILITY
(since T1 accesses t through a cursor)
36
 CURSOR STABILITY
CURSOR STABILITY does not solve all problems
• Does not eliminate all lost updates: T1 accesses t
through cursor, T2 (also at CURSOR STABILITY)
accesses t directly (e.g., through an index)

T1: fetch(t) update(t) commit

T2: r(t) update(t) commit
• Can be prone to deadlock: Both T1 and T2 accesses
t through cursor,

T1: fetch(t) request_update(t)

T2 : fetch(t) request_update(t)
37
 Update Locks
• Some DBMS provide update locks to alleviate
deadlock problem
• A transaction that wants to read an item now
and possibly update it later requests an
update lock on the item (manual locking)
– An update lock is a read lock that can be
upgraded to a write lock
• Often used with updatable cursors

38
 Update Locks

• An update lock conflicts with other update locks

and with write locks, but not with read locks.

Granted mode
Requested mode read write update
read x
write x x x
update x x

39
 Update Locks
• Schedule that causes a deadlock at CURSOR
STABILITY:
T1: fetch(t) request_update(t)
T2: fetch(t) request_update(t)

• If both fetches had requested update locks,

T2’s fetch would be made to wait until T1 had
completed, avoiding the deadlock

40
 OPTIMISTIC READ COMMITTED

Some systems provide a version of READ COMMITTED

called OPTIMISTIC READ COMMITTED
• Transactions get the same short-term read locks on
tuples as at READ COMMITTED
• If such a transaction, T, later tries to write a tuple it has
previously read, if some other transaction has written
that tuple and then committed, T is aborted

41
 OPTIMISTIC READ COMMITTED

• Called optimistic because the transaction

optimistically assumes that no transaction
will write what it has read and hence it gives
up its read lock
– If that assumption is not true, it is aborted.

• Prevents lost updates, but can still lead to

nonserializable schedules

42
 Sometimes Good Things Happen

• For some applications, schedules are serializable

and/or correct even though transactions are
executing at isolation levels < SERIALIZABLE

• Designers must analyze applications to determine

correctness

43
 Correct Execution at READ
UNCOMMITTED
• Example: Print_Alumni_Transcript(s)
– Reads Transcript table and prints a transcript
for a student, s, that has graduated. Since no
concurrently executing transaction will be
updating s’s record, the transaction executes
correctly at READ UNCOMMITTED

44
 Correct Execution READ COMMITTED
• Example - Register(s,c)
– Step 1: Read table Requires to determine c’s prerequisites
– Step 2: Read table Transcript to check that s has completed all of c’s prerequisites
– Step 3: Read table Transcript to check that s does not enroll for more than 20 credits
– Step 4: If there is room in c, update Class:

– Step 5: Insert row for s in Transcript

UPDATE Class C
SET C.Enrollment = C.Enrollment +1
WHERE C.CrsCode = c AND C.Enrollment < C.MaxEnrollment

45
 Possible Interactions
• Register(s,c) executed at READ COMMITTED
concurrently with a transaction that adds/deletes
prerequisite for c
– either Register sees new prerequisite or does not

Register: SEL(Requires); SEL(Transcript); UPD(Class); INS(Transcript)

Add_Prereq: INS(Requires)

• However, application specification states that

prerequisites added this semester do not apply to the
registration this semester, but the following semester
– Hence it does not matter if Register sees new prerequisite
46
 Possible Interactions
• Register(s,c) executed at READ COMMITTED concurrently with a
transaction that registers another student in c
– Can a lost update occur and the Enrollment exceed
MaxEnrollment?
– No, since check and increment are done in a single (isolated)
UPDATE over enrollment and lost update not possible
• registers the same student in a different class
– Each can execute step 3 and determine that the 20 credit
maximum is not exceeded
– Each can then complete and the maximum can be exceeded
– Each does not see the phantom inserted in Transcript by the
other
– But this interaction might be ignored since it is highly unlikely

47
 Possible Interactions

• These checks are necessary, but not

sufficient to guarantee correct execution
– Must look at interactions with other
transactions
– Schedules involving multiple transactions
that might be non-serializable

48
Serializable, SERIALIZABLE & Correct

• Serializable - Equivalent to a serial schedule

• SERIALIZABLE - An SQL isolation level
defined in the standard
• Correct - Leaves the database consistent and
a correct model of the real world

49
Serializable, SERIALIZABLE & Correct

• If a schedule is serializable, it is correct

• If a schedule is produced at SERIALIZABLE
isolation level, it is serializable, hence correct
• But as we have seen ...

50
Serializable, SERIALIZABLE & Correct

• All schedules of an application run at an

isolation level lower than SERIALIZABLE
might be serializable
• A schedule can be correct, but not serializable
• One challenge of the application designer is to
design applications that execute correctly at
the lowest isolation level possible

51
 Granular Locks

• Transactions access data at different

levels of granularity
• Many DBMSs provide both fine and
coarse granularity locks
– DBMS attempts to automatically choose
appropriate granularity
– A particular application might be able to
force a particular granularity

52
 Granular Locks

Problem:
• T1 holds a (fine grained) lock on field F1 in record R1.
• T2 requests a conflicting (coarse grained) lock on R1.

How does the concurrency control detect the conflict

since it sees F1 and R1 as different items?

53
 Granular Locks (GL)

Solution:
• Organize locks hierarchically by containment and
• Require that a transaction to get a fine grained lock it
– must first get a coarse grained lock on the containing item

Hence, T1 must:
• First get a lock on R1
• Before getting a lock on F1.
The conflict with T2 is detected at R1.

54
 Intention Locking

Performance improvement: if lock on parent is weak

• Intention shared (IS): to get an S lock on an item, T
must first get IS locks on all containing items (root)
• Intention exclusive (IX): to get an X lock on an item, T
must first get IX locks on all containing items (root)
• Shared Intention Exclusive (SIX): Equivalent to an
S lock and an IX lock on an item
Intention lock indicates transaction’s intention to
acquire conventional lock on a contained item

55
 Conflict Table
Requested Granted mode
mode IS IX S X SIX
IS x
IX x x x
S x x x
X x x x x x
SIX x x x x
• Example 1: T2 denied an IX lock (intends to update
some contained items) since T1 is reading all
contained items
• Example 2: T2 granted IS lock even though T1 holds IX
lock (since they may be accessing different subsets of
contained items)
56
 Preventing Phantoms
• Lock entire table - this works
– T1 executes SEL(P): (where P is a predicate),
obtains long-duration S lock on table
– T2 executes INS(t): requires long-duration
X lock on table
– Phantom prevented
• Lock the predicate P - this works but entails too
much overhead
• Can granular locking be used?

57
 No Appropriate Index for P
• Assume containment hierarchy is table/pages:
• T1 does SEL(P): obtains long-duration S lock on table
– Since it must read every page to find rows satisfying P
• T2 requests INS(t): obtains long-duration IX lock on
table (lock conflict detected) and X lock on page into
which t is to be inserted.
– Hence (a potential) phantom is prevented
– However other transaction can read parts of the table that
are stored on pages other than the one on which t is
stored

58
 Index I exists on attribute P
• T1 obtains long-duration IS lock on table, uses I
to locate pages containing rows satisfying P,
and acquires long-duration S locks on them.
• T2 obtains long-duration IX lock on table (no
conflict) and X lock on page p, into which
t is to be inserted.
– Problem: Since p might not be locked by T1, a
phantom can result.

59
 Index Locking
• Solution: lock pages of the index in addition
• Example: I is an unclustered B+ tree.
– T1 obtains:
• long-duration IS lock on table,
• long-duration S locks on the pages containing rows
satisfying P, and
• long-duration S locks on the leaf index pages
containing entries satisfying P
– T2 requests:
• long-duration IX lock on table (granted),
• long-duration X locks on the page into which t is to be
inserted (might be granted), and
• long-duration X lock on the leaf index page into which
the index entry for t will be stored (lock conflict if t
satisfies P)
– The phantom is prevented.
60
 Index Locking - Example
T1: SELECT F.Name
FROM Faculty F
WHERE F.Salary > 70000 unclustered
index on
Holds: IS lock on Faculty, Salary
S lock on a, b, d, e
S lock on e

Faculty

a b c d
T2: INSERT INTO Faculty
VALUES (…75000, …)
inserted row
Requests: IX lock on Faculty,
X lock on c, X lock on e 61
 Index, Predicate & Key-Range Locks
If a WHERE clause:
• refers to a predicate name = mary and if
• there is an index on name,
then an index lock on index entries for name = mary
• is like a predicate lock on that predicate

If a WHERE clause refers to a

• predicate such as 50000< salary < 70000 and if
• there is an index on salary,
then a key-range index lock can be used to get the
• equivalent of a predicate lock on 50000<salary<70000

62
 Key-Range Locking
• Instead of locking index pages, index entries at
the leaf level are locked
– Each such lock is interpreted as a lock on a range
• Suppose the domain of an attribute is A…Z and
suppose at some time the entries in the index are
CGPRX
• A lock on G is interpreted as a lock on the half-
open interval
[G P) which includes G but not P

63
 Key-Range Locking (cont)

• Recall the index entries are: C G P R X

• Two special cases
– A lock on X locks everything greater than X
– A new lock must be provided for [A C)
• Then for example to lock the interval
H < K < Q, we would lock G and P

64
 Key-Range Locking (cont)
• Recall the index entries are: C G P R X
• To insert a new key, J, in the index
– Lock G thus locking the interval [G P)
– Insert J thus splitting the interval into [G J) [J P)
– Lock J thus locking [J P)
– Release the lock on G
• If a SELECT statement had a lock on G as part of a
key-range, then the first step of the insert
protocol could not be done
– Thus phantoms are prevented and the key-range
lock is equivalent to a predicate lock
65
 Locking a B-Tree Index
• Many operations need to access an index structure
concurrently
– This would be a bottleneck if conventional two-
phase locking mechanisms were used
• Understanding index semantics, we can develop a
more efficient locking algorithm
– Goal is to maintain isolation among different
operations, concurrently accessing the index
– The short term locks on the index are called latches
– The long term locks on leaf entries we have been
discussing are still obtained
66
 Read Locks on a B-Tree Index

• Obtain a read lock on the root, and work down

the tree locking each entry as it is reached

• When a new entry is locked, the lock on the

previous entry (its parent) can be released
– This operation will never revisit the parent
– No write operation of a concurrent transaction can
pass this operation as it goes down the tree
– Called lock coupling or crabbing

67
 Write Locks on a B-Tree Index
• Obtain a write lock on the root, and work down
the tree locking each entry as it is reached
• When new entry n is locked, if that entry is not
full, the locks on all its parents can be released
– An insert operation might have to go back up the
tree, revisiting and perhaps splitting some nodes
– Even if that occurs, because n is not full, it will
not have to split n and therefore will not have to
go further up the tree
– Thus it can release locks further up in the tree.

68
Granular and Index Locking Summary

• Algorithm has property that a lock conflict

that prevents phantoms will occur:
– In the index, when an index is used
– At the table level, when no index is used

• Even if there is no index, write operations

need not get an X lock on whole table, only
an IX lock, which allows more concurrency

69
 UPDATE Statement

• An UPDATE can be treated as if it were a

DELETE followed by an INSERT
– If an index attribute is changed, the index entry
for the tuple must be moved to a new position
– The transaction must obtain write locks on both
the old and new index pages

70
 Lock Escalation

• To avoid acquiring many fine grain locks on a

table, a DBMS can set a lock escalation
threshold.
• If more than the threshold number of tuple (or
page) locks are acquired, the DBMS
automatically trades them in for a table lock
but …

• Beware of deadlock

71
 GL in an Object Database

• Containment hierarchy exists in two ways in

an object database
– Class contains object instances
– Class contains subclasses (and hence object
instances of subclasses)
• Intentions locking can be used over this
hierarchy in the same way as in
table/page/row hierarchy

72
 Granular Locking Protocol for
Object Databases
• Before obtaining a lock on an object instance,
the system must obtain the appropriate
intention locks on the object’s class and all
the ancestor classes

• Before obtaining a lock on a class, the

system must get the appropriate intention
locks on all ancestors of that class

73
 Performance Hints
• Use lowest correct isolation level
• Embedding constraints in schema might permit
the use of an even lower level
– Constraint violation due to interleaving detected at
commit time (an optimistic approach)
• No user interaction after a lock has been acquired
• Use indexes and denormalization to support
frequently executed transactions
• Avoid deadlocks by controlling the order in which
locks are acquired

74
 Multiversion Controls (MVCs)
• Version: a snapshot of the database containing the
updates of all and only committed transactions

w1(x) w2(y) c1 w3(x) w2(z) c2

create version 1 create version 2
(contains updates (contains updates of
of T1, but not T2) T1 and T2, but not T3)

• A multi-version DBMS maintains all versions

created in the (recent) past
• Major goal of a multi-version DBMS: avoid the need
for read locks

75
 Read-Consistency
• All DBMSs guarantee that statements are isolated:
– Each statement sees state produced by the complete
execution of other statements, but state might not be
committed
• A MVC guarantees that each statement sees a committed
state:
– Statement executed in a state whose value is a version
– Referred to as statement-level read consistency
• A MVC can also guarantee that all statements of a
transaction see the same committed state:
– All statements of a transaction access same version
– Referred to as transaction-level read consistency

76
 Read-Only MVC
• Distinguishes in advance read-only (R/O)
transactions from read/write (R/W) transactions.
– R/W transactions use a (conventional) immediate-
update, pessimistic control. Hence, transactions
access the most current version of the database.
– All the reads of a particular R/O transaction TRO
are satisfied using the most recent version that
existed when TRO requested its first read.

77
 Read-Only MVC
• Assuming R/W transactions are executed at
SERIALIZABLE, all schedules are serializable:
– R/W transactions are serialized in commit order.
– Each R/O transaction is serialized after the
transaction that created the version it read.
– Equivalent serial order is not commit order.
• All transactions see transaction-level read
consistency.

78
 Example

r1(x) w1(y) r2(x) c1 w2(x) r3(x) w2(y) c2 r3(y) c3

• T1 and T2 are read/write, T3 is read/only

• T3 sees the version produced by T1
• The equivalent serial order is T1 T3 T2

79
 Implementation
• DBMS maintains a version counter (VC).
– Incremented each time a R/W transaction commits.
• The new version of a data item created by a R/W
transaction is tagged with the value of VC at the
time the transaction commits.
• When a R/O transaction makes its 1st read request,
the value of VC becomes its counter value.
– Each request to read an item is satisfied by the
version of the item having the largest version
number less than or equal to the transaction’s
counter value.
80
 Multiversion Database
x y z u
v1 v2 v1 v4
17 a .223 38

v2 v3 v5
22 ab .24

v3 v6
123 abf

• Values read by a R/O transaction with counter value 4

81
 Read-Only Multiversion Control

• R/O transactions do not use read locks.

– They never wait.
– They never cause R/W transactions to wait.

82
 Read-Consistency MVC
• R/O transactions:
– As before: get transaction-level read consistency.
• R/W transactions:
– Write statements acquire long-duration write locks
(delay other write statements)
– Read statements use most recent (committed)
version at time of read
• Not delayed by write locks, since read locks are
not requested.

83
 Example

w1(x) w1(y) r2(x) c1 w2(x) r3(x) r2(y) w2(y) c2 r3(y) c3

• T1 and T2 are R/W, T3 is R/O.

• T3 uses v1.
• T2 takes the value of x from v0, y from v1.
• There is no equivalent serial order.

84
 Read-Consistency MVC

• Satisfies ANSI definition of READ COMMITTED

isolation level, but in addition ...
– Provides transaction-level read consistency for
R/O transactions
– No read locks: reads do not wait for writes and
writes do not wait for reads
• Version of READ COMMITTED supported by Oracle.

85
 SNAPSHOT Isolation
• Does not distinguish between R/W and R/O
transactions
• A transaction reads the most recent version that
existed at the time of its first read request
– Guarantees transaction-level read consistency
• The write sets of any two concurrently executing
transactions must be disjoint
• Two implementations of this specification
– First Committer Wins
– Locking implementation
86
First Committer Wins Implementation

• Writes use deferred-update (intentions list).

• T is allowed to commit only if no concurrent

transaction:
– committed before T,
– updated a data item that T also updated.

87
 First Committer Wins
to intentions list
T1: r(xn) w(x) request_commit
T2: r(xn) w(x) request_commit
abort
counter value = n commit and
create w(xn+1)
• Control is optimistic:
– It can be implemented without any locks
– Deadlock not possible
– Validation (write set intersection) is required for
R/W transactions and abort is possible
– Schedules might not be serializable
88
 Locking Implementation of
SNAPSHOT Isolation

• Immediate update pessimistic control

• Reads do not get any locks and execute as
in the previous implementation

89
 Locking Implementation of
SNAPSHOT Isolation

• A transaction T that wants to perform a write on

some item I must request a write lock
– If the version number of I is greater than that of T,
T is aborted (first committer wins)
– Otherwise, if another transaction T’ has a write
lock on that item, T waits until that T’ completes
• If T’ commits, T is aborted (first committer wins)
• If T’ aborts, T is given the write lock and allowed to write

90
 Anomalies at SNAPSHOT Isolation
• Many anomalies are impossible:
– Dirty read, dirty write, non-repeatable read, lost update
• However, schedules might not be serializable.
• Example:
T1: r(a:10) r(b:10) w(a:-5) commit
T2: r(a:10) r(b:10) w(b:-5) commit

– Constraint a+b0 violated

– Referred to as write skew

91
 Phantoms at SNAPSHOT Isolation
Audit:
SELECT SUM (balance)
FROM Accounts NewAccnt:
WHERE name = ‘Mary’ INSERT INTO Accounts
VALUES (‘123’,‘Mary’,100)
UPDATE Depositors
SET totbal = totbal + 100
SELECT totbal WHERE name = ‘Mary’
FROM Depositors
WHERE name = ‘Mary’
• Both transactions commit.
• All reads of a transaction satisfied from the same version.
• Hence Audit works correctly.
92
 Phantoms at SNAPSHOT Isolation

• After a transaction executes SELECT, a

concurrent transaction might insert a phantom
– If the SELECT is repeated, the phantom will not be
in the result set
– Therefore, apparently, phantoms cannot occur at
SNAPSHOT isolation
• But …

93
 Phantoms at SNAPSHOT Isolation
• Non-serializable schedules due to phantoms
are possible
• Example: concurrent transactions each execute
SEL(P) and then insert a row satisfying P
– Neither sees the row inserted by the other.
– The schedule is not serializable.
– This would be considered a phantom if it occurred
at REPEATABLE READ.
– Can be considered write skew

94
 Correct Execution at
SNAPSHOT Isolation

• Many applications execute correctly at

SNAPSHOT isolation, even though schedules
are not serializable
• Example: reserving seats for a concert
– Integrity constraint: a seat cannot be reserved
by more than one person

95
 Reserving Seats for a Concert
• A reservation transaction checks the status of two
seats and then reserves one that is free
– Schedule below is non-serializable, but is correct
and preserves the constraint

T1: r(s1:Free) r(s2:Free) w(s1:Res) commit

T2: r(s1:Free) r(s2:Free) w(s2:Res) commit

– Alternatively, if both transactions had tried to

reserve the same seat

T1: r(s1:Free) r(s2:Free) w(s1:Res) abort

T2: r(s1:Free) r(s2:Free) w(s1:Res) commit
96
 Not Serializable, but Correct

• Note that the first schedule on the previous slide

has a write skew and is not serializable
– Neverthless it is correct for this application!

97