Lec 9
Concurrency Control Techniques
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Chapter Outline

Databases Concurrency Control
1.
2.
3.
4.
5.
6.
Purpose of Concurrency Control
Two-Phase locking
Limitations of CCMs
Index Locking
Lock Compatibility Matrix
Lock Granularity
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 2
Database Concurrency Control

1 Purpose of Concurrency Control




To enforce Isolation (through mutual exclusion) among
conflicting transactions.
To preserve database consistency through consistency
preserving execution of transactions.
To resolve read-write and write-write conflicts.
Example:

In concurrent execution environment if T1 conflicts with T2
over a data item A, then the existing concurrency control
decides if T1 or T2 should get the A and if the other
transaction is rolled-back or waits.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 3
Two-Phase Locking Techniques

Locking is an operation which secures



Example:



Lock (X). Data item X is locked in behalf of the requesting
transaction.
Unlocking is an operation which removes these permissions
from the data item.
Example:


(a) permission to Read
(b) permission to Write a data item for a transaction.
Unlock (X): Data item X is made available to all other
transactions.
There are three locking operations:
Read_lock(X), write_lock(X), unlock(X)
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 4
Two-Phase Locking Techniques:
Essential components

Multiple-mode lock:


More than one transaction can apply share lock on X for
reading its value but no write lock can be applied on X by any
other transaction.
Exclusive mode: Write lock (X)


(b) exclusive (write).
Shared mode: shared lock (X)


(a) shared (read)
Only one write lock on X can exist at any time and no shared
lock can be applied by any other transaction on X.
Conflict matrix
Read
Write
Read
Y
N
Write
N
N
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 5
Two-Phase Locking Techniques:
Essential components

Lock Manager:


Managing locks on data items.
Lock table:

Lock manager uses it to store the identify of
transaction locking a data item, the data item, lock
mode and pointer to the next data item locked. One
simple way to implement a lock table is through
linked list.
Transaction ID Data item id lock mode Ptr to next data item
T1
X1
Read
Next
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 6
Two-Phase Locking Techniques:
Essential components

Database requires that all transactions should be
well-formed. A transaction is well-formed if:


It must lock the data item before it reads or writes to
it.
It must not lock an already locked data items and it
must not try to unlock a free data item.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 7
Database Concurrency Control
Two-Phase Locking Techniques: Essential components

The following code performs the read operation:
B: if LOCK (X) = “unlocked” then
begin LOCK (X)  “read-locked”;
no_of_reads (X)  1;
end
else if LOCK (X)  “read-locked” then
no_of_reads (X)  no_of_reads (X) +1
else begin wait (until LOCK (X) = “unlocked” and
the lock manager wakes up the transaction);
go to B
end;
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 8
Database Concurrency Control
Two-Phase Locking Techniques: Essential components

The following code performs the write lock operation:
B: if LOCK (X) = “unlocked”
then LOCK (X) )  “write-locked”
else begin
wait (until LOCK (X) = “unlocked”
and the lock manager wakes up the transaction);
go to B
end;
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 9
Database Concurrency Control
Two-Phase Locking Techniques: Essential components

The following code performs the unlock operation:
if LOCK (X) = “write-locked” then
begin LOCK (X)  “unlocked”;
wakes up one of the transactions, if any
end
else if LOCK (X)  “read-locked” then
begin
no_of_reads (X)  no_of_reads (X) -1
if no_of_reads (X) = 0 then
begin
LOCK (X) = “unlocked”;
wake up one of the transactions, if any
end
end;
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 10
Conversion of locks

Lock conversion
 Lock upgrade: existing read lock to write lock
if Ti has a read-lock (X) and Tj has no read-lock (X) (i  j) then
convert read-lock (X) to write-lock (X)
else
force Ti to wait until Tj unlocks X

Lock downgrade: existing write lock to read lock
Ti has a write-lock (X) (*no transaction can have any lock on X*)
convert write-lock (X) to read-lock (X)
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 11
Two-Phase Locking Techniques:


A transaction is said to follow the Two-Phase locking protocol if all
locking operations (read_lock,write_lock) precede the first unlock
operation in the transaction.
Two-Phase locking protocol:
1)
Locking (Growing) Phase:

2)
Unlocking (Shrinking) Phase:


A transaction applies locks (read or write) on desired data items one
at a time.
A transaction unlocks its locked data items one at a time.
Requirement:
 For a transaction these two phases must be mutually exclusively,
that is, during locking phase unlocking phase must not start and
during unlocking phase locking phase must not begin.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 12
Two phase locking
Locks of Ti
growing
shrinking
time
Each transaction has to follow, no locking anymore
after the first unlocking
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Transactions that do not obey two-phase
locking
T1
T2
Result
read_lock (Y);
read_item (Y);
unlock (Y);
write_lock (X);
read_item (X);
X:=X+Y;
write_item (X);
unlock (X);
read_lock (X);
read_item (X);
unlock (X);
Write_lock (Y);
read_item (Y);
Y:=X+Y;
write_item (Y);
unlock (Y);
Initial values: X=20; Y=30
Result of serial execution
T1 followed by T2
X=50, Y=80.
Result of serial execution
T2 followed by T1
X=70, Y=50
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 14
Cont.
Two-Phase Locking Techniques: The algorithm
T1
T2
read_lock (Y);
read_item (Y);
unlock (Y);
Result
X=50; Y=50
Nonserializable because it.
violated two-phase policy.
read_lock (X);
read_item (X);
unlock (X);
write_lock (Y);
read_item (Y);
Y:=X+Y;
write_item (Y);
unlock (Y);
Time
write_lock (X);
read_item (X);
X:=X+Y;
write_item (X);
unlock (X);
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 15
Cont.

Transactions T1 and T2 of the previous figure do
not follow the two-phase locking protocol
because the write_lock(X) operation follows the
unlock(Y) operation in T1, and similarly the
write_lock(Y) operation follows the unlock(X)
operation in T2.

If we enforce two-phase locking , the transactions
can be rewritten as T’1 and T’2 in next slide
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 16
Cont.
T’1
T’2
read_lock (Y);
read_item (Y);
write_lock (X);
unlock (Y);
read_item (X);
X:=X+Y;
write_item (X);
unlock (X);
read_lock (X);
read_item (X);
Write_lock (Y);
unlock (X);
read_item (Y);
Y:=X+Y;
write_item (Y);
unlock (Y);
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
T1 and T2 follow two-phase
policy but they are subject to
deadlock, which must be
dealt with.
Slide 18- 17
Two-Phase Locking Techniques

There are a number of variations of two-phase locking (2PL). The
two-phase locking techniques as follows:

Basic:
 Transaction locks data items incrementally. This may cause
deadlock which is dealt with.

Conservative (static):
 Prevents deadlock by locking all desired data items it access
before the transaction begins execution.

Strict:
 unlocking is performed after a transaction terminates (commits or
aborts). This is the most commonly used two-phase locking
techniques.
 Is not deadlock-free.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 18
Conservative 2PL

Difficult but deadlock free
first action starts
locks
growing
time
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
shrinking
Strict 2PL

T does not release any write locks until it commits
or aborts
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Dealing with Deadlock and Starvation
Deadlock
T’1
T’2
read_lock (Y);
read_item (Y);
T1 and T2 did follow two-phase
policy but they are deadlock
read_lock (X);
read_item (X);
write_lock (X);
(waits for X)

write_lock (Y);
(waits for Y)
Illustrating the deadlock problem. A partial schedule T’1 and T’2
that is in a state of deadlock.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 21
Dealing with Deadlock and Starvation

Deadlock prevention



A transaction locks all data items it needed before
it begins execution.
This way of locking prevents deadlock since a
transaction never waits for a data item.
The conservative two-phase locking uses this
approach.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 22
Dealing with Deadlock and Starvation

Deadlock detection and resolution

In this approach, deadlocks are allowed to happen. The
system construct and maintain a wait-for-graph for
detecting cycle. If a cycle exists, then one transaction
involved in the cycle is selected (victim) abort and rolledback.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 23
Dealing with Deadlock and Starvation

Starvation

Starvation occurs when a particular transaction waits or
restarted and never gets a chance to proceed further.

In a deadlock resolution it is possible that the same
transaction may be selected as victim and rolled-back.

One solution for starvation is to have a fair waiting scheme,
such as using a first-come-first-served queue;
transactions are enabled to lock an item in the order in
which they originally requested the lock.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 24
Concurrency Control based on
Timestamp ordering

Timestamp




is a unique identifier created by the DBMS to identify a
transaction.
Typically, timestamp values are assigned in the order
in which the transactions are submitted to the system,
so a timestamp can be thought of as the transaction
start time.
We will refer to the timestamp of transaction T as
TS(T).
Concurrency control techniques based on timestamp
ordering do not use locks; hence, deadlocks cannot
occur.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 25
Cont.
Timestamps can be generated in several ways:
 One possibility is to use a counter that is incremented
each time its value is assigned to a transaction. The
transaction timestamps are numbered 1, 2, 3, ... in this
scheme. A computer counter has a finite maximum value,
so the system must periodically reset the counter to zero
when no transactions are executing for some short period
of time.
 Another way to implement timestamps is to use the
current date/time value of the system clock and ensure
that no two timestamp values are generated during the
same tick of the clock.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 26
The Timestamp Ordering Algorithm
The algorithm must ensure that, for each item accessed by conflicting
operations in the schedule, the order in which the item is accessed
does not violate the serializability order. To do this, the algorithm
associates with each database item X two timestamp (TS) values:
1- Read_TS(X): The read timestamp of item Xi this is the largest
timestamp among all the timestamps of transactions that have
successfully read item X-that is, read_TS(X) = TS(T), where T is the
youngest transaction that has read X successfully.
2- Write_TS(X): The write timestamp of item Xi this is the largest of all
the timestamps of transactions that have successfully written item Xthat is, write_TS(X) = TS(T), where T is the youngest transaction that
has written X successfully.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 27
Basic Timestamp Ordering
1- Transaction T issues a read_item(X) operation:


If write_TS(X) > TS(T), then abort and roll back T and reject the
operation. This should be done because some younger
transaction with timestamp greater than TS(T)-and hence after T
in the timestamp ordering-has already written the value of item X
before T had a chance to read X.
If write_TS(X) :s; TS(T), then execute the read_item(X) operation
of T and set read_TS(X) to the larger of TS(T) and the current
read_TS(X).
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 28
Basic Timestamp Ordering
2- Transaction T issues a write_item(X) operation:

If read_TS(X) > TS(T) or if write_TS(X) > TS(T), then abort and roll
back T and reject the operation. This should be done because some
younger transaction with a timestamp greater than TS(T)-and hence
after T in the timestamp ordering-has already read or written the
value of item X before T had a chance to write X, thus violating the
timestamp ordering.

If the condition in part (a) does not occur, then execute the
write_tem(X) operation ofT and set write_TS(X) to TS(T).
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 29
Thomas’s Write Rule
If read_TS(X) > TS(T) then abort and roll-back T and reject the
operation.


If write_TS(X) > TS(T), then do not execute the write operation but
continue processing. This is because some transaction with
timestamp greater than TS(T)-and hence after T in the timestamp
ordering-has already written the value of X. Hence, we must ignore
the wri te_i tem(X) operation of T because it is already outdated and
obsolete.

If the conditions given in 1 and 2 above do not occur, then execute
write_item(X) of T and set write_TS(X) to TS(T).
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 30
Validation (Optimistic) Concurrency
Control Schemes


In this technique only at the time of commit serializability
is checked and transactions are aborted in case of nonserializable schedules.
There are three phases for this concurrency control
protocol:
1. Read and execution phase:

During this phase, the system execute transaction Ti.
It read the values of the various data items and stores
them in variables local to Ti. It performs all write
operations on temporary local variables without
updates of the actual database.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 31
Validation (Optimistic) Concurrency
Control Schemes
2. Validation phase:
Transactions Ti performs a validation test to determine if
local variables can be written without violating
seializability.
3. Write phase:
If Ti is validated successfully (step2), the updates are
applied to the database; otherwise, Ti is rolled back.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 32
Validation-based protocol
To perform the validation test, we need to know when the
phases of transaction Ti took place.
Thus, each transaction Ti is associated three timestamp:
1)
Start(Ti): the time when Ti started its execution.
2)
Validation(Ti): the time when Ti entered its validation
phase.
3)
Finish(Ti): the time when Ti finished its write phase.
Serializability order is determined by timestamp given at
validation time., to increase concurrency. Thus TS(Ti) is
given the value of validation(Ti).
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 33
Validation test for transaction Tj
The validation test for transaction Tj requires that, for all
transaction Ti with TS(Ti)< TS(Tj), one of the following two
conditions holds:
 Finish (Ti)<Start(Tj) since Ti completes its execution
before Tj started, the serializability order is then
maintained.
 Start(Tj)<Finish(Ti)<Validation(Tj) and the set of data
items written by Ti does not intersect with the set of data
items read by Tj.
Then validation succeeds and Tj can be committed.
Otherwise, validation fails and Tj is aborted.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 34
Granularity of data items and Multiple
Granularity Locking



A lockable unit of data defines its granularity. Granularity
can be coarse (entire database) or it can be fine (a tuple
or an attribute of a relation).
Data item granularity significantly affects concurrency
control performance. Thus, the degree of concurrency is
low for coarse granularity and high for fine granularity.
Example of data item granularity:
1.
2.
3.
4.
5.
A field of a database record (an attribute of a tuple)
A database record (a tuple or a relation)
A disk block
An entire file
The entire database
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 35
Cont.

A granularity hierarchy illustrates multiple
granularity level locking from coarse (database)
to fine (record).
DB
f1
p11
p12
f2
...
p1n
p11
p12
...
p1n
r111 ... r11j r111 ... r11j r111 ... r11j r111 ... r11j r111 ... r11j r111 ... r11j
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 36
Cont.

To manage such hierarchy, in addition to read (shared)
and write (exclusive), three additional locking modes,
called intention lock modes are defined:



Intention-shared (IS): indicates that a shared lock(s) will be
requested on some descendent nodes(s).
Intention-exclusive (IX): indicates that an exclusive lock(s)
will be requested on some descendent node(s).
Shared-intention-exclusive (SIX): indicates that the
current node is locked in shared mode but an exclusive
lock(s) will be requested on some descendent nodes(s).
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 37
Cont.

Lock compatibility matrix for multiple granularity
locking:
IS
IS yes
IX yes
yes
S
SIX yes
X no
IX
yes
yes
no
no
no
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
S
SIX
yes yes
no no
yes no
no no
no no
X
no
no
no
no
no
Slide 18- 38
Cont.

Transaction Ti can lock a node using the following rules for producing
serializable schedule:
1. The lock compatibility matrix must be observed.
2. The root of the tree must be locked first, in any mode..
3. A node N can be locked by a transaction T in S or IX mode only if
the parent node is already locked by T in either IS or IX mode.
4. A node N can be locked by T in X, IX, or SIX mode only if the
parent of N is already locked by T in either IX or SIX mode.
5. T can lock a node only if it has not unlocked any node (to enforce
2PL policy).
6. T can unlock a node, N, only if none of the children of N are
currently locked by T.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 39
Consider we have the following three transaction:

T 1 wants to update record r111 and record r211.
T2 wants to update all records on page P12.

T3 wants to read record r11j and the entire f2 file.

The next figure shows a possible serializable
schedule for these three transaction
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 40
Lock operations to illustrate a
serializable schedule
T1
T2
T3
____________________________________________
IX(db)
IX(f1)
IX(db)
IS(db)
IS(f1)
IS(p11)
IX(p11)
X(r111)
IX(f1)
X(p12)
S(r11j)
IX(f2)
IX(p21)
IX(r211)
Unlock (r211)
Unlock (p21)
Unlock (f2)
S(f2)
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 41
Cont.
T1
T2
T3
_________________________________________
unlock(p12)
unlock(f1)
unlock(db)
unlock(r111)
unlock(p11)
unlock(f1)
unlock(db)
unlock (r111j)
unlock (p11)
unlock (f1)
unlock(f2)
unlock(db)
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Slide 18- 42