Lecture 10: Concurrency Control

Motivating Questions
How does Concurrency control work ?
Why is it important for DBMS ?
What is 2PL?

Connelly & Begg Ch 20

Database Architecture
DBMS transaction subsystem 4 high level
database modules that handle transactions,
concurrency control and recovery.
Transaction Manager (TM) coordinates
transactions on behalf of application
programs
TM communicates with Scheduler/lock
manager implement strategy to maximize
concurrency control. If failure occurs during
transaction, then database is in inconsistent
state.
Recovery manager ensure database is
restored or consistent state.
Buffer Manager responsible for the
efficient transfer of data between disk
storage and main memory.
Concurrency Control
Concurrency control - the process of managing
simultaneous operations on the database without having
them interfere with one another
Concurrency control is needed to prevent concurrent
transactions from interfering with each other.
Consider the scenario:
two or more users accessing database simultaneously
and at least one is updating data, there may be
interference that can result in inconsistencies
Concurrency Control
Interleaved transaction - allows multiple users of the
database to access it at the same time.
While one transaction is performing an I/O task, another
one can perform a CPU-intensive task thus maximising the
throughput of the system.
Throughput the amount of work that is accomplished in
a given time interval
Interleaving of operations may produce an incorrect
result/problems, thus compromising the integrity and
consistency of the database.
Concurrency Control
Concurrency control is needed to handle problems that can
occur when transactions execute concurrently.
Lost Update problem: an update to an object by some
transaction is overwritten by another interleaved transaction
without knowledge of the initial update.
Uncommitted Dependency problem: a transaction reads an
object updated by another transaction that later falls.
Inconsistent Analysis problem: a transaction calculating an
aggregate function uses some but not all updated objects of
another transaction.
Lost Update Example
Time T
1
T
2
bal
x

t
1

t
2

t
3

t
4

t
5

t
6


begin_transaction
read(bal
x
)
bal
x
= bal
x
- 100
write (bal
x
)
commit
begin_transaction
read(bal
x
)
bal
x
= bal
x
+ 100
write (bal
x
)
commit

100
100
100
200
90
90
T
1
and T
2
start at nearly the same time, both read the balance as RM100.
T
2
increased bal
x
by RM100 to RM200 and stores the update in the database
Meanwhile T
1
decrements its copy of bal
x
, by RM10 to RM90 and stores in
database, overwriting the previous update, and loosing the RM100 previously
added to the balance.
The loss of T
2
s update is avoided by preventing T
1
from sending the value of
bal
x
until after T
2
s update has been completed

Lost Uncommited dependency
(or dirty read)
T
4
updates bal
x
to RM200 but it aborts the transaction so that bal
x
should be restored to its
original value of RM100.
By this time T
3
has read the new value of bal
x
RM200 and is using this value as the basis of
the RM10 reduction, giving a new incorrect balance of RM190, instead of RM90.
The value of bal
x
read by T
3
is called dirty data, giving rise to the alternative name, the
dirty read problem
The problem is avoided by preventing T
3
from reading bal
x
until after the decision has been
made to either commit or abort T
4
s effect
Time T
3
T
4
bal
x

t
1

t
2

t
3

t
4

t
5

t
6

t
7

t
8




begin_transaction
read(bal
x
)
bal
x
= bal
x
+ 10
write (bal
x
)
commit
begin_transaction
read(bal
x
)
bal
x
= bal
x
+ 100
write (bal
x
)
:
rollback

100
100
100
200
200
100
190
190
Lost Update Example
read (R)
Add 50 to R
read (R)
Add 100 to R
write (R)

write (R)
T
A
T
B
Transaction As update is lost
Locks
In order to execute transactions in an interleaved
manner it is necessary to have some form of
concurrency control.
This enables a more efficient use of computer
resources.
One method of avoiding problems is with the use
of locks.
When a transaction requires a database object it
must obtain a lock.
Lock Manager
A lock is obtained from a system component called the
lock manager.
There are usually two types of lock an exclusive lock (X)
and a shared lock (S).
The lost update problem can easily be handled by X
locks.
When a transaction intends to update an object it must
obtain an X lock on it. If one is not available it must wait.
Transaction A can obtain an X lock on R and then
Transaction B will have to wait before it can have an X
lock on R.
Lost Update Solution
Begin
x_lock(R)
read (R)
Add 50 to R Begin
x_lock(R)
wait
write (R) wait
Commit/unx_lock(R) wait
read (R)
Add 100 to R
write (R)
commit/unx_lock(R)
T
A
T
B
Uncommitted Dependency Example
read (R)
Subtract 50 from R
write (R)
read (R)
Add 75 to R
write (R)
ROLLBACK
T
A
T
B
Transaction B reads an uncommitted value for R
Uncommitted Dependency Example
Problems can still occur if a transaction is ROLLED back.
The uncommitted dependency problem can be solved by
an extension to the locking protocol.
Exclusive locks are retained until the end of a transaction.
Transaction B would not be allowed an X lock on R until
transaction B had completed (either COMMITT or ROLL
BACK).
Uncommitted Dependency Solution #
Begin
x_lock(R)
read (R)
Subtract 50 from R Begin
x_lock(R)
wait
write (R) wait
Rollback/unx_lock(R) wait
read (R)
Add 75 to R
write (R)
commit/unx_lock(R)
T
A
T
B
Inconsistent Analysis Example
read (ACC1)
SUM = ACC1
read (ACC2)
SUM = SUM + ACC2
read (ACC1)
ADD 10 to ACC1
read (ACC3)
SUBTRACT 10 from ACC3
WRITE(ACC3)
COMMIT
read (ACC3)
SUM = SUM + ACC3
T
A
T
B
The value in SUM will be inconsistent.
Required SUM = 120 but is 110.
ACC1 = 30
ACC2 = 40
ACC3 = 50
Inconsistent Analysis Problem
A transaction may need to keep an object locked
even if it is not updating it.
In the Inconsistent analysis problem it is
necessary for Transaction A to obtain an S lock on
each account and retain these locks until the
transaction is complete.
Inconsistent Analysis Solution #
Begin
s_lock(ACC1), s_lock(ACC2),s_lock(ACC3)
read (ACC1)
SUM = ACC1
read (ACC2)
SUM = SUM + ACC2 Begin
x_lock(ACC1),x_lock(ACC3)
wait
read (ACC3) wait
SUM = SUM + ACC3 wait
uns_lock(ACC1),uns_lock(ACC2),uns_lock(ACC3) wait
read (ACC1)
Add 10 to ACC1
read (ACC3)
subtract 10 from ACC3
write(ACC3)
commit/unx_lock(ACC1),unx_lock(ACC3)
T
A
T
B
Locking - a procedure used to control concurrent access to
data. When one transaction is accessing the database, a lock may
deny access to other transactions to prevent incorrect results.
Locking methods widely used approach to ensure serialisability
of concurrent transactions.
Transaction will claim shared lock (read) or exclusive lock
(write) on a data item before the corresponding database read or
write operation.
Shared lock if a transaction has a shared lock on a data item,
it can read the item but not update it
Exclusive lock if a transaction has an exclusive lock on a data
item, it can both read and update the item.

Locking Methods
Locks can only be acquired according to the compatibility
matrix.

T
A
has
S X
T
B
requests S Y N
X N N

A transaction may set a lock on an item if this lock is
compatible with locks already held on the item by other
transactions
Lock Compatibility Matrix
Locking Rules
Any number of transactions can hold S-locks on an item
If any transaction holds an X-lock on an item, no other
transaction may hold any lock on the item
A transaction holding an X-lock may issue a write or a
read request on the data item
A transaction holding an S-lock may issue a read request
on the data item
Serialisability
A given interleaved execution of a set of
transactions is considered correct if it is
serialisable.
A given interleaved execution of a set of
transactions is said to be serialisable if and
only if it produces the same results as some
serial execution of the same transactions.
Justification of Serialisability
Individual transactions are assumed to be
correct.
Running the transactions one at a time in
any serial order is therefore also correct.
An interleaved execution is therefore
correct if it is equivalent to some serial
execution; i.e it is serialisable.
Serialisability applied to examples
In the earlier examples the original interleaved
executions were not equivalent to either running
T
A
then T
B
or T
B
then T
A
.
The effect of locking was to force serialisability.
It is possible to guarantee serialisability by using
the two-phase locking protocol.
Two-Phase Locking Protocol (2PL)
2PL a transaction follows the two-phase locking protocol if all
locking operations precede the first unlock operation in the
transaction
1. Before operating on an object, a transaction must acquire a
lock on that object
2. After releasing a lock, a transaction must never acquire any
new locks.
The protocol guarantees serialisability
A transaction obeying this protocol will have two phases a
growing phase during which locks are obtained and a
shrinking phase when locks are released.
The shrinking phase is often compressed into the single
operation COMMIT or ROLLBACK.
Incorrect Locking Question #
read (A)
Add 10 to A
write (A)
read (B)
subtract 10 from B
write (B)
T
A
T
B
read (A)
A = A * 1.2
write (A)
read (B)
B = B * 1.2
write(B)
Incorrect Locking Answer #
X_lock (A)
read (A)
Add 10 to A
write (A)
unX_lock(A)
X_lock (A)
read (A)
A = A * 1.2
write (A)
X_lock (B)
read (B)
B = B * 1.2
write(B)
unX_lock (A),unX_lock (B)
X_lock (B)
read (B)
subtract 10 from B
write (B)
unX_lock(B)
T
A
T
B
Example of 2PL
S_lock (Y)
read (Y)
X_lock (X)
unlock (Y)
X_lock (Y)
read (Y)
write (Y)
read (X)
write (X)
unlock (X)
S_lock (X)
read (X)
unlock (X)
unlock (Y)
T
A
T
B
2PL with Lock Conversion
Growing Phase
can acquire an S-lock on item
can acquire an X-lock on item
can convert an S-lock to an X-lock
Shrinking Phase
can release an S-lock
can release an X-lock
can convert an X-lock to an S-lock
Deadlock
X_lock (R)
read (R)
X_lock (S)
read (S)
request X_lock(S)
wait request X_lock(R)
wait wait
wait wait

T
A
T
B
Deadlock occurs when two transactions are each waiting
for locks held by the other to be released
Example
Deadlock Prevention
If a deadlock occurs then the system needs to detect it.
Detecting deadlock involves detecting a cycle in the wait-
for graph i.e the graph of who is waiting for whom.
Breaking the deadlock then involves choosing one of the
transactions and rolling it back, thereby releasing its locks
and allowing other transactions to proceed.
In practise some systems just use a timeout mechanism and
assume deadlock if a transaction has done nothing for a
prescribed period of time.
Timestamp Protocol
Each transaction is issued a unique identifier, the
timestamp when it enters the system. Timestamps may be
drawn from an increasing sequence of integers.
For any given request, the system compares the timestamp
of the requesting transaction with the timestamp of the
transaction that last retrieved or updated that object.
Conflicts occur if a transaction asks to see an object last
seen or updated by a younger transaction.
Conflicts are dealt with by restarting the requesting
transaction and assigning it a new timestamp.
Timestamp Example #
TB
TA
write(C)
Request read or write on C
Transaction TA
is older than
transaction TB
AND
last write is by TB
Timestamp Example #
TB
TA write(C)
Request read or write on C
Transaction TA
is younger than
transaction TB
AND
last write is by TB
Recovery and Concurrency Control:
Summary
Concurrency control problems occur when transactions are
not serialisable.
The most widespread technique for dealing with such
problems is locking.
A set of transactions obeying the two-phase locking
protocol can be guaranteed serialisable.
What You Should Now Know
What the Lost Update, Uncommitted
Dependency and Inconsistent Analysis
problems are and how they are resolved by
locks.
How locks work.
What serialisability is and how 2PL works.
What deadlock is and how it is prevented.
What timestamps are and how they work.