Advanced Database Technologies

Instructor: Eric Umuhoza, PhD

Email: [email protected]
Twitter: @EricUmuhoza

June 25, 2023

1 / 76
 Concurrency Control

Concurrency Control

• A DBMS serve many applications, and respond to many users.

• The application load of a DBMS can be measured using the
number of transactions per second (tps) managed by the
DBMS to satisfy the needs of applications.
• Typical systems (e.g, financial information systems, booking
systems of large airlines or credit card management) manage
thousands of tps.
• Hundreds or thousands of tps cannot be executed sequentially

Concurrency is fundamental

2 / 76
 Concurrency Control

Concurrency Control

3 / 76
 Concurrency Control

Concurrent Executions

4 / 76
 Concurrency Control

Concurrency Control

• The concurrency control system refers to the lowest level in the

architecture of a DBMS, relative to the input/output
operations, which carry out the transfer of blocks between the
secondary memory and the main memory
• Each read operation consists of the transfer of a block from the
secondary memory to the main memory and each write
operation consists of the opposite transfer.
• The read and write operations are managed by the scheduler,
which determines whether the requests can be satisfied

5 / 76
 Concurrency Control

Architecture of the concurrency control system

Note: We will be using an abstract description of the database in terms of

objects x, y, z to refer to numeric data, but in reality reading and writing
them requires the reading and writing of the whole page on which the data
is to be found.

6 / 76
 Concurrency Control

Example of Concurrency

• Two transactions:
T1:
UPDATE a c c o u n t
SET b a l a n c e = b a l a n c e + 3
WHERE c l i e n t = ’ Smith ’
T2:
UPDATE a c c o u n t
SET b a l a n c e = b a l a n c e + 6
WHERE c l i e n t = ’ Smith ’

7 / 76
 Concurrency Control

Serial Executions

b o t ( T1 ) b o t ( T2 )
r (D, x ) r (D, y )
x=x+3 y=y+6
w( x ,D) w( y , D) D0 = 0
commit commit
e o t ( T1 ) e o t ( T2 )

8 / 76
 Concurrency Control

Problems due to Concurrency

• Problem: concurrent execution may cause anomalies

– Lost updates
– Dirty read
– Non-repeatable reads
– Phantom updated

Concurrency needs to be controlled!

9 / 76
 Concurrency Control

Execution with Lost Update

S=100
1. T1: R(S,V1) T1: UPDATE account
SET balance = balance + 3
2. V1 = V1 + 3
WHERE client = ’Smith’
3. T2: R(S,V2)
T2: UPDATE account
4. V2 = V2 + 6 SET balance = balance + 6
WHERE client = ’Smith’
5. T1: W(V1,S) S=103
6. T2: W(V2,S) S=106!

This anomaly is called a lost update, because the effects of the

first transaction to write the new value for s are lost.

10 / 76
 Concurrency Control

Sequence of I/O Actions Producing the Error

11 / 76
 Concurrency Control

Dirty Read
S=100
1. T1: R(S,V1)
T1: UPDATE account
2. T1: V1 = V1 + 3 SET balance = balance + 3
3. T1: W(V1,S) S=103 WHERE client = ’Smith’

4. T2: R(S,V2) T2: UPDATE account

SET balance = balance + 6
5. T1: ROLLBACK WHERE client = ’Smith’
6. T2: V2 = V2 + 6
7. T2: W(V2,S) S=109!

T2 sees an intermediate state, produced by the transaction T1 which

subsequently carries out an abort.
This anomaly is known as dirty read, as a piece of data is read that
represents an intermediate state in the processing of a transaction.

12 / 76
 Concurrency Control

Non-repeatable Read

S=100
T1: SELECT balance FROM account
1. T1: R(S,V1) S=100 WHERE client = ’Smith’
UPDATE account
2. T2: R(S,V2) S=100 SET balance = balance + 3
3. T2: V2 = V2 + 6 WHERE client = ’Smith’
4. T2: W(V2,S) S=106 T2: UPDATE account
SET balance = balance + 6
5. T1: R(S,V3) V36=V1 WHERE client = ’Smith’
6. ...
For T1, S assumes the value 100 after the first read and the value
106 after the second read. Instead, it is convenient that a transaction
that accesses the database twice finds exactly the same value for
each piece of data read, and is not affected by the other transaction.

13 / 76
 Concurrency Control

Phantom Update
• Consider a DB with three objects, X, Y and Z which satisfy an
integrity constraint: X+Y+Z=100
• Initial state: X=50, Y=30, Z=20
T1: R(X,V1), R(Y,V2)
T2: R(Y,V3), R(Z,V4)
T2: V3 = V3 + 10, V4=V4-10
T2: W(V3,Y), W(V4,Z) (Y=40, Z=10)
T1: R(Z,V5) (But for T1, X+Y+Z=90!)

T1 observes only some of the effects of T2, and thus observes a state
that does not satisfy the integrity constraints. This anomaly is called
a Phantom or Ghost update.

14 / 76
 Concurrency Control

Anomalies

• Lost update R-R-W-W

• Dirty read R-W-R-abort-W
• Nonrepeatable read R-R-W-R
• Phantom update R-R-W-R

15 / 76
 Concurrency Control

Preliminary Definitions

• We define a transaction as a sequence of read or write actions

• Assumptions
1 Each transaction has a unique identifier
2 No transaction reads or writes the same object more than once
• Examples of transactions
1 T1 : r1 (x) w1 (x)
2 T2 : r2 (z) w2 (z)

Schedule
• A Schedule is sequence of input/output operations
performed by concurrent transactions.
• E.g., S1 : r1 (x) r2 (z) w1 (x) w2 (z)

16 / 76
 Concurrency Control

Principles of Concurrency Control

• Goal: to reject schedules that cause anomalies

• Scheduler: component that accepts or rejects the operations
requested by the transactions
• Serial schedule: the actions of each transaction occur in
contiguous sequences

S2 : r0 (x) r0 (y) w0 (z) r1 (y) r1 (x) w1 (y) r2 (x) r2 (y) r2 (z) w2 (z)

17 / 76
 Concurrency Control

Principles of Concurrency Control

The execution of the commit-projection of a given schedule Si is

correct when it produces the same result as some serial schedule
Sj of the same transactions. In this case, we say that Si is serializable

• Serializable schedule produces the same results as some

serial schedule on the same transactions

18 / 76
 Concurrency Control

Principles (Theory) of Concurrency Control

• Requires a notion of schedule equivalence

1 View equivalence (VSR)
2 Conflict equivalence (CSR)

• Note
– Efficiency: cost of equivalence checking
– Efficacy: classes of acceptable schedules

The larger the acceptable classes of schedules the higher the costs
of equivalence checking

19 / 76
 Concurrency Control

Assumption

• We assume that transactions are observed in the ’past’ and we

want to decide whether the corresponding schedule is correct
• Commit-projection: Schedules contain only the transactions
that produce a commit.
• Notice that, in practice, schedulers need to decide while the
transaction is running
– We will need to remove such assumption

20 / 76
 Concurrency Control

View-serializability

Preliminary definition

• ri (x) reads-from wj (x) in a schedule S when wj (x) precedes

ri (x) in S and there is no wk (x) between ri (x) and wj (x) in
S
• wi (x) in a schedule S is a final write if it is the last write
on x that occurs in S

• Two schedules are view-equivalent (Si ≈V Sj ): if they have the

same reads-from relations and the same final writes
• A schedule is view-serializable if it is equivalent to a serial
schedule
• VSR is the set of view-serializable schedules

21 / 76
 Concurrency Control

Examples of View-serializability

S3 : w0 (x) r2 (x) r1 (x) w2 (x) w2 (z)

S4 : w0 (x) r1 (x) r2 (x) w2 (x) w2 (z)

S3 is view-equivalent to serial schedule S4 (so it is view-

serializable)

S5 : w0 (x) r1 (x) w1 (x) r2 (x) w1 (z)

S6 : w0 (x) r1 (x) w1 (x) w1 (z) r2 (x)

S5 is view-equivalent to serial schedule S6 (so it is view-

serializable)

22 / 76
 Concurrency Control

Examples of View-serializability 2

S7 : r1 (x) r2 (x) w1 (x) w2 (x)

S8 : r1 (x) r2 (x) w1 (x) r1 (x)
S9 : r1 (x) r1 (y) r2 (z) r2 (y) w2 (y) w2 (z) r1 (z)
S7 corresponds to a lost update
S8 corresponds to a non-repeatable read
S9 corresponds to a phantom update

They are all non view-serializable

23 / 76
 Concurrency Control

More Complex Example 1

• W0 (x),r1 (x),w0 (z),r1 (z),r2 (x),w0 (y),r3 (z),w3 (z),w2 (y),w1 (x),w3 (y)

• W0 (x),w0 (z),w0 (y),r1 (x),r1 (z),w1 (x),r2 (x),w2 (y),r3 (z),w3 (z),w3 (y)

Reads-from: r1 (x) from w0 (x),

r1 (z) from w0 (z),
r2 (x) from w0 (x) and from w1 (x)!!!
r3 (z) from w0 (z),
Final writes: w1 (x), w3 (y), w3 (z)

24 / 76
 Concurrency Control

More Complex Example 2

• W0 (x),r1 (x),w0 (z),r1 (z),r2 (x),w0 (y),r3 (z),w3 (z),w2 (y),w1 (x),w3 (y)

• W0 (x),w0 (z),w0 (y),r2 (x),w2 (y),r1 (x),r1 (z),w1 (x),r3 (z),w3 (z),w3 (y)

Reads-from: r1 (x) from w0 (x),

r1 (z) from w0 (z),
r2 (x) from w0 (x) and from w1 (x)!!!
r3 (z) from w0 (z),
Final writes: w1 (x), w3 (y), w3 (z)

25 / 76
 Concurrency Control

Complexity of View-serializability

• Deciding view-equivalence of two given schedules can be done

in polynomial time
• Deciding view-serializability of a generic schedule is an
NP-complete problem since it requires to determine whether a
schedule is view-equivalent to any serial schedule.

NP-Complete problems are a class of problems for which there is

no known solution algorithm with a polynomial complexity, and
as such they are regarded as intractable.

26 / 76
 Concurrency Control

Conflict-serializability

Preliminary definition

Action ai is conflicting with aj (i 6=j) if both are operations on a

common data item and at least one of them is a write operation
• read-write conflicts (rw or wr)
• write-write conflicts (ww)

27 / 76
 Concurrency Control

Conflict-serializability

• Conflict-equivalent schedules (Si ≈C Sj ): Si and Sj contain the

same operations and all conflicting operation pairs occur in the
same order
• S is a conflict-serializable schedule if it is conflict-equivalent to a
serial schedule
• CSR is the set of conflict-serializable schedules

28 / 76
 Concurrency Control

CSR and VSR

• Every conflict-serializable schedule is also view-serializable,

but the converse is not necessarily true
• Counter-example:
r1 (x) w2 (x) w1 (x) w3 (x)

View-serializable: view-equivalent to
r1 (x) w1 (x) w2 (x) w3 (x)

Not conflict-serializable, due to the presence of: r1 (x) w2 (x)

and w2 (x) w1 (x)

29 / 76
 Concurrency Control

CSR and VSR

30 / 76
 Concurrency Control

Testing Conflict-serializability

• Testing conflict-serializability is done with a conflict graph that

has:
1 One node for each transaction Ti
2 One arc from Ti to Tj if there exists at least one conflict between an
action ai of Ti and an action aj of Tj such that ai precedes aj

Theorem
A schedule is in CSR iff its conflict graph is acyclic.

31 / 76
 Concurrency Control

Example Test

w0 (x),r1 (x),w0 (z),r1 (z),r2 (x),w0 (y),r3 (z),w3 (z),w2 (y), w1 (x),w3 (y)

32 / 76
 Concurrency Control

CSR implies Acyclicity of the Conflict Graph

• Consider a schedule S in CSR. As such it is ≈C to a serial

schedule
• Suppose the order of transactions in the serial schedule is:
t1 , t2 , ..., tn
• Since the serial schedule has all conflicting pairs in the same order
as schedule S, in S’s graph there can only be arcs (i,j), with i<j
• Then the graph is acyclic, as a cycle requires at least an arc (i,j)
with i>j

33 / 76
 Concurrency Control

Properties of the Conflict Graph

• If S’s graph is acyclic then it has a topological sort, i.e., an

ordering of the nodes such that the graph only contains arcs (i,j)
with i<j
• The serial schedule whose transactions are ordered according
to the topological sort is conflict-equivalent to S, because
for all conflicting pairs (i,j) it is always i<j
– In the example before: T0 < T2 < T1 < T3
– In general there can be MANY topological sorts (i.e. serializations for
the same acyclic graph)
< : relation of precedence

34 / 76
 Concurrency Control

Concurrency Control in Practice

• The analysis of cyclicity of a graph has a linear complexity

w.r.t the size of the graph itself.
• This technique would be efficient if we knew the graph from the
beginning — but we don’t.
• A scheduler must work incrementally, i.e., for each requested
operation it should decide whether to execute it immediately or
do something else.
• It is not feasible to maintain the graph, update it and verify its
acyclicity at each operation request.

We need other tools and techniques.

35 / 76
 Concurrency Control

Locking

• It’s the most common method in commercial systems

• A transaction is well-formed wrt locking if:
– read operations are preceded by r lock (SHARED LOCK) and followed
by unlock
– write operations are preceded by w lock (EXCLUSIVE LOCK) and
followed by unlock

• When a transaction first reads and then writes an object it can:

– use a w lock
– modify r lock into a w lock (lock escalation)

36 / 76
 Concurrency Control

Lock Primitives

Primitives
• r lock: read lock
• w lock: write lock
• unlock

Possible states of an object

• free
• r locked (locked by a reader)
• w locked (locked by a writer)

37 / 76
 Concurrency Control

Behavior of the Lock Manager

• The lock manager receives the primitives from the transactions

and grants resources according to the conflict table
– When a lock request is granted, the resource is acquired
– When an unlock is executed, the resource becomes available

Lock Resource State

Request
Free r locked w locked
r lock OK, r locked OK, r locked NO, w locked
w lock OK, w locked NO, r locked NO, w locked
unlock Error OK, depends OK, free

38 / 76
 Concurrency Control

Two-Phase Locking

• Requirements:
– A transaction cannot acquire any other lock after releasing a lock
– Locks on a transaction can be released only after commit/abort
operations

39 / 76
 Concurrency Control

Serializability

• If a scheduler
1 uses well-formed transactions;
2 grants locks according to conflicts; and
3 is two-phase
• Then it produces the schedule class called 2PL

Schedules in 2PL are serializable

40 / 76
 Concurrency Control

2PL and CSR

• Every 2PL schedule is also conflict-serializable, but the

converse is not necessarily true.
• Counter-example:
r1 (x) w1 (x) r2 (x) w2 (x) r3 (y) w1 (y)
• It violates 2PL:
r1 (x) w1 (x) ↑ r2 (x) w2 (x) r3 (y) ↑ w1 (y)
T1 releases T1 acquires
• However, it is conflict-serializable

T3 < T1 < T2

41 / 76
 Concurrency Control

CSR, VSR and 2PL

42 / 76
 Concurrency Control

Strict 2PL

• We were still using the hypothesis of commit-projection

• To remove this hypothesis, we need to add a constraint to 2PL,
thus obtaining strict 2PL:
– Locks on a transaction can be released only after commit/rollback
• This version of 2PL is used in commercial DBMSs

43 / 76
 Concurrency Control

Strict 2PL in Practice

44 / 76
 Concurrency Control

Implementation of 2-Phase Locking

• Lock tables are in reality main memory data structures

– Resource state is either Free, or Read-Locked, or Write-locked
– To keep track of readers, every resource has also a read counter
– Some late-ninety systems only supported exclusive locks (means:
binary info for resources, no counter)
• A transaction asking for a lock is either granted a lock or
queued and suspended, the queue is first-in first-out;
there is a danger of:
– Deadlock: two or more transactions in endless wait
Typically occurs when each transaction waits for another to release a
lock (in particular: r1 r2 w1 w2 → update lock)
– Starvation: individual transaction waiting forever
Starvation can occur for write transactions waiting for resources which
are highly used for reading (e.g. index roots).

45 / 76
 Concurrency Control

Isolation Levels in SQL:1999 (and JDBC)

• Writes are always applied strict 2PL (so update loss is avoided)
• READ UNCOMMITTED allows dirty reads, non repeatable reads
and phantoms:
– No read lock (and ignores locks of other transactions)
• READ COMMITTED avoids dirty reads but allows non
repeatable reads and phantoms:
– Read locks (and complies with locks of other transactions), but
without 2PL
• REPEATABLE READ avoids dirty reads, non repeatable reads
and phantom updates, but allows phantom inserts:
– 2PL also for reads, with data locks
• SERIALIZABLE avoids all anomalies (default):
– 2PL with predicate locks
On the entire relation
On the index

46 / 76
 Concurrency Control

Predicate Lock

• A transaction T = update Tab set B=1 where A=1

• Then, the lock is on predicate A=1
– Other transactions cannot insert, delete, or update any tuple satisfying
this predicate
– In the worst case (predicate locks not supported):
The lock extends to the entire table
– In case the implementation supports predicate locks:
The lock is expressed with the help of indexes
• Predicate locks protect from phantom inserts, as the insertion
of new data affecting a running query is forbidden

47 / 76
 Concurrency Control

Hierarchical Locking

• In many real systems, locks are specified with different levels of

granularity:
– e.g., database, table, fragment, page, tuple, field
• These resources are in a hierarchy (or in a directed acyclic graph
(DAG))
• The choice of the lock granularity depends on the application:
1 Too coarse: too many locked resources → little concurrency
2 Too fine: too many lock requests → too much overhead

48 / 76
 Concurrency Control

Hierarchical Locking

• Concept:
– Locking can be done upon objects at various levels of granularity.
• Objectives:
– Setting the minimum number of lockings
– Recognizing conflicts as soon as possible
• Organization: asking locking upon resources organized as a
hierarchy
– Requesting resources top-down until the right level is obtained
– Releasing locks bottom-up.

49 / 76
 Concurrency Control

Hierarchy of Resources: Example

50 / 76
 Concurrency Control

Resources Managed through Hierarchical Locking

51 / 76
 Concurrency Control

Hierarchical Locking Modes

• Five lock modes:

1 XL: exclusive lock, corresponds to the write-lock of the 2pl protocol;
2 SL: shared lock, corresponds to the read-lock of the 2pl protocol;
3 ISL: intention shared lock. It expresses the intention of locking in a
shared manner one of the nodes that descend from the current node;
4 IXL: intention exclusive lock. This expresses the intention of exclusively
locking one of the nodes descending from the current node;
5 SIXL: shared intention-exclusive lock. This locks the current node in a
shared mode and expresses the intention of exclusively locking one of
the nodes descending from the current node.

52 / 76
 Concurrency Control

Hierarchical Locking Protocol

1 Lock requests are done starting from the root and going down in
the hierarchy.
2 Locks are released from the lowest level and then going up in the
hierarchy.
3 To request an SL or ISL lock on a non-root node, a transaction
must hold an ISL or IXL lock on its parent node.
4 To request an IXL, XL or SIXL lock on a non-root node, a
transaction must hold a SIXL or IXL lock on its parent node.

53 / 76
 Concurrency Control

Conflicts in Hierarchical Locks

Compatibility among the lock functions in the presence of hierarchies.

Request Resource State

ISL IXL SL SIXL XL
ISL OK OK OK OK No
IXL OK OK No No No
SL OK No OK No No
SIXL OK No No No No
XL No No No No No

54 / 76
 Concurrency Control

Example

• Page 1: T1,T2,T3,T4
• Page 2: T5,T6,T7,T8
• Transaction 1:
1 read(P1)
2 write(T3)
3 read(T8)

• Transaction 2:
1 read(T2)
2 read(T4)
3 write(T5)
4 write(T6)
They are NOT in conflict!

55 / 76
 Concurrency Control

Lock Sequences

Assumption: Transaction 1 precedes Transaction 2

• Transaction 1:
1 IXL(root)
2 SIXL(P1)
3 XL(T3)
4 ISL(P2)
5 SL(T8)

• Transaction 2:
1 IXL(root) – OK, (IXL,IXL)
2 ISL(P1) – OK, (ISL,SIXL)
3 SL(T2) – OK, Free
4 SL(T4) – OK, Free
5 IXL(P2) – OK, (IXL, ISL)
6 XL(T5) – OK, Free
7 XL(T6) – OK, Free
56 / 76
 Concurrency Control

Deadlock

• Occurs because concurrent transactions hold and, in turn, require

resources held by other transactions
• T1 :r1 (x) w1 (y)
• T2 :r2 (y) w2 (x)
S: r lock1 (x) r lock2 (y) r1 (x) r2 (y) w lock1 (y) w lock2 (x)

• The probability of a deadlock increases linearly wrt the number of

transactions and quadratically wrt the number of locks requested
by each transaction

57 / 76
 Concurrency Control

Deadlock

• A deadlock is represented by a cycle in the Wait-For graph of

the resources

58 / 76
 Concurrency Control

Deadlock Resolution Techniques

• Timeout
– Transactions killed after a long wait
• Deadlock prevention
– Transactions killed when they could be in deadlock
• Deadlock detection
– Transactions killed when they are in deadlock

59 / 76
 Concurrency Control

Timeout Method

• A transaction is killed after given waiting, assuming it is involved

in a deadlock
• Simplest, most used method
• Timeout value is system-determined (sometimes it can be altered
by the database administrator)
• The problem is choosing a proper value
– Too long: useless wait
– Too short: unrequired kills

60 / 76
 Concurrency Control

Deadlock Prevention

• Kills transactions that could cause cycles

• One possible scheme is:
– assigning transaction numbers (assigning transactions an age)
– killing transactions when older transactions wait for younger
transactions
• Options for choosing the transaction to kill
– Pre-emptive (killing the transaction holding the resource)
– Non-pre-emptive (killing the requesting transaction)
• The problem: too many killings (waiting probability vs deadlock
probability)

61 / 76
 Concurrency Control

Deadlock Detection

• Requires an algorithm for finding real cycles in the wait-for graph

– Must work with distributed resources

– Must be efficient and reliable
• The best solution: Obermark’s algorithm (DB2-IBM, published
on ACM-Transactions on Database Systems)
– Assumes synchronous transactions, each transaction works at a single
site
– Assumes communications via remote procedure calls
Both assumptions can be easily removed

62 / 76
 Concurrency Control

Deadlocks in Practice

• Their probability is much less than the conflict probability

– Consider a file with n records and two transactions doing two access to
their records (uniform distribution); then:
Conflict probability is O(1/n)
Deadlock probability is O(1/n2 )
• They do occur (once every minute for a mid-size bank)
• Probability rises linearly with the number of transactions and
quadratically with transaction size (number of lock requests)

63 / 76
 Concurrency Control

Update Lock

• The most frequent deadlock occurs when 2 concurrent

transactions start by reading the same resource (SL) and then
decide to write it and try to upgrade their lock to XL
• To avoid this situation, systems offer the Update Lock(UL) –
asked by transactions that will read and then write an item

Request Resource
SL UL XL
SL OK OK No
UL OK No No
XL No No No

64 / 76
 Concurrency Control

Concurrency Control Based on Timestamps

• Alternative to 2PL
• Timestamp: identifier defining a total ordering of the events of
a system
• Each transaction has a timestamp representing the time at which
the transaction begins
• A schedule is accepted only if it reflects the serial ordering of the
transactions induced by their timestamps

65 / 76
 Concurrency Control

Timestamp Mechanism

• The scheduler has two counters for each object: RTM(x) and
WTM(x)
• The scheduler receives read and write requests with timestamp:
– read(x,ts):
If ts < WTM(x) the request is rejected and the transaction killed
Else, the request is granted and RTM(x) is set to max(RTM(x), ts)
– write(x,ts):
If ts < WTM(x) or ts < RTM(x) the request is rejected and the
transaction killed
Else, the request is granted and WTM(x) is set to ts

No transaction can read or write an item of data written by a trans-

action with a greater timestamp, and cannot write on an item of data
that has already been read by a transaction with a greater timestamp.

66 / 76
 Concurrency Control

Timestamp: Problems

• Many transactions are killed

• To work without the commit-projection hypothesis, it needs to
buffer write operations until commit, which introduces waits

67 / 76
 Concurrency Control

Timestamp: Example

Assume RTM(x) = 7
WTM(x) = 4

Request New value

Response
read(x,6)
OK
read(x,8) RTM(x) = 8
OK
read(x,9) RTM(x) = 9
OK
write(x,8) t8 killed
No
write(x,11) WTM(x) = 11
OK
read(x,10) t10 killed
No

68 / 76
 Concurrency Control

2PL vs. TS

• They are incomparable

– Schedule in TS but not in 2PL
r1 (x) w1 (x) r2 (x) w2 (x) r0 (y) w1 (y)
– Schedule in 2PL but not in TS
r2 (x) w2 (x)r1 (x) w1 (x)
– Schedule in TS and in 2PL
r1 (x) r2 (y) w2 (y) w1 (x) r2 (x) w2 (x)
• Besides: r2 (x) w2 (x) r1 (x) w1 (x) is serial but not in TS

69 / 76
 Concurrency Control

CSR, VSR, 2PL and TS

70 / 76
 Concurrency Control

2PL vs. TS

• In 2PL transactions can be waiting. In TS they are killed and

restarted

• The serialization order with 2PL is imposed by conflicts, while in

TS it is imposed by the timestamps

• 2PL can cause deadlocks (but also TS if care is not taken)

• Restarting a transaction costs more than waiting: 2PL wins!

71 / 76
 Concurrency Control

Multiversion Concurrency Control

Idea
Writes generate new copies, reads access the right copy.

• Writes generate new copies, each one with a new WTM. Each
object x always has N > 1 active copies with WTMN (x). There
is a unique global RTM(x)

• Old copies are discarded when there are no transactions that

need these values

72 / 76
 Concurrency Control

Multiversion Concurrency Control

Mechanism
• Read(x,ts) is always accepted. A copy xk is selected for
reading such that:
• If ts > WTMN (x), then k = N
• Else take k such that WTMk (x) < ts < WTMk+1 (x)

• Write(x,ts):
• If ts < RTM(x), the request is rejected
• Else a new version is created (N is incremented)
with WTMN (x) = ts

73 / 76
 Concurrency Control

Example

Assume RTM(x) = 7
N=1 WTM(x1 ) = 4
Request Response New value
read(x,6) OK
read(x,8) OK RTM(x) = 8
read(x,9) OK RTM(x) = 9
write(x,8) No t8 killed
write(x,11) OK N=2, WTM(x2 ) = 11
read(x,10) OK on 1 RTM(x) = 10
read(x,12) OK on 2 RTM(x) = 12
write(x,13) OK N=3, WTM(x3 ) = 13

74 / 76
 Concurrency Control

CSR, VSR, 2PL, TSmono, TSmulti

75 / 76
Concurrency Control

The End

76 / 76