Chapter 18

Concurrency Control Techniques

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe

Chapter 18 Outline
 Databases Concurrency Control
1. Purpose of Concurrency Control
2. Two-Phase locking
3. Limitations of CCMs
4. Index Locking
5. Lock Compatibility Matrix
6. 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

Types of Locks
 Binary Locks
 Has 2 values or states
 Locked -1
 Unlocked - 0

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 18- 4

Database Concurrency Control
Two-Phase Locking Techniques
 Locking is an operation which secures
 (a) permission to Read
 (b) permission to Write a data item for a transaction.
 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:
 Unlock (X): Data item X is made available to all other
transactions.
 Lock and Unlock are Atomic operations.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 18- 5

Database Concurrency Control
Two-Phase Locking Techniques: Essential components
 Two locks modes:
 (a) shared (read) (b) exclusive (write).
 Shared mode: shared lock (X)
 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)
 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- 6

Database Concurrency Control
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- 7
Database Concurrency Control
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- 8

Database Concurrency Control
Two-Phase Locking Techniques: Essential components
 The following code performs the lock operation:

Lock_item(X):
B: if LOCK (X) = 0 (*item is unlocked*)
then LOCK (X)  1 (*lock the item*)
else begin
wait (until lock (X) = 0) and
the lock manager wakes up the transaction);
goto 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:

Unlock_item(X):
LOCK (X)  0 (*unlock the item*)
if any transactions are waiting then
wake up one of the waiting the transactions;

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 18- 10

Lock and Unlock Operations for
Binary Lock

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 18- 11

Binary Locking Scheme
 If the simple binary locking scheme described is used, every
transaction must obey the following rules:
1. A transaction T must issue the operation lock_item(X)
before any read_item(X) or write_item(X) operations are
performed in T.
2. A transaction T must issue the operation unlock_item(X)
after all read_item(X) and write_item(X) operations are
completed in T.
3. A transaction T will not issue a lock_item(X) operation if it
already holds the lock on item X ’.
4. A transaction T will not issue an unlock_item(X) operation
unless it already holds the lock on item X.
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 18- 12
Shared / Exclusive (or Read/Write) Locks
 The preceding binary locking scheme is too restrictive for database
items because at most, one transaction can hold a lock on a given
item.
 We should allow several transactions to access the same item X if
they all access X for reading purposes only. This is because read
operations on the same item by different transactions are not
conflicting
 However, if a transaction is to write an item X, it must have exclusive
access to X.
 For this purpose, a different type of lock called a multiple-mode lock
is used.
 In this scheme—called shared/exclusive or read/write locks—there
are three locking operations: read_lock(X), write_lock(X), and
unlock(X).

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 18- 13

Shared / Exclusive (or Read/Write) Locks
 A lock associated with an item X, LOCK(X), now
has three possible states: read-locked, write-
locked, or unlocked.
 A read-locked item is also called share-locked
because other transactions are allowed to read
the item, whereas a write-locked item is called
exclusive-locked because a single transaction
exclusively holds the lock on the item.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 18- 14

Locking and unlocking operations for two-mode
(read-write or shared-exclusive) locks.
read_lock(X):
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- 15

Locking and unlocking operations for two-mode
(read-write or shared-exclusive) locks.

write_lock(X):
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- 16

Locking and unlocking operations for two-mode
(read-write or shared-exclusive) locks.
unlock (X):
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- 17

Locking and unlocking operations for two-mode
(read-write or shared-exclusive) locks.
 When we use the shared/exclusive locking scheme, the system must
enforce the following rules:
1. A transaction T must issue the operation read_lock(X) or write_lock(X)
before any read_item(X) operation is performed in T.
2. A transaction T must issue the operation write_lock(X) before any
write_item(X) operation is performed in T.
3. A transaction T must issue the operation unlock(X) after all
read_item(X) and write_item(X) operations are completed in T.
4. A transaction T will not issue a read_lock(X) operation if it already holds
a read (shared) lock or a write (exclusive) lock on item X. This rule may
be relaxed.
5. A transaction T will not issue a write_lock(X) operation if it already
holds a read (shared) lock or write (exclusive) lock on item X. This rule
may also be relaxed,.
6. A transaction T will not issue an unlock(X) operation unless it already
holds a read (shared) lock or a write (exclusive) lock on item X.Slide 18- 18
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe
Conversion of Locks
Two-Phase Locking Techniques: Essential components
 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- 19

Guaranteeing Serializability by
Two-Phase Locking
Two-Phase Locking Techniques: The algorithm
 Two Phases:
 (a) Locking (Growing or Expanding or First phase)

 (b) Unlocking (Shrinking or Second phase).

 Locking (Growing) Phase:

 A transaction applies locks (read or write) on desired data items

one at a time.
 Unlocking (Shrinking) Phase:
 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- 20

Guaranteeing Serializability by
Two-Phase Locking

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 18- 21

Guaranteeing Serializability by
Two-Phase Locking

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 18- 22

Guaranteeing Serializability by
Two-Phase Locking

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 18- 23

Database Concurrency Control
Two-Phase Locking Techniques: The algorithm
 Two-phase policy generates two locking algorithms
 (a) Basic

 (b) Conservative

 Conservative:
 Prevents deadlock by locking all desired data items before
transaction begins execution.
 Basic:
 Transaction locks data items incrementally. This may cause
deadlock which is dealt with.
 Strict:
 A more stricter version of Basic algorithm where unlocking is
performed after a transaction terminates (commits or aborts and
rolled-back). This is the most commonly used two-phase locking
algorithm.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 18- 24

Dealing with Deadlock and Starvation

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 18- 25

Database Concurrency Control
Dealing with Deadlock and Starvation
 Deadlock prevention

 A transaction locks all data items it refers to 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- 26

Database Concurrency Control
Dealing with Deadlock and Starvation
 Deadlock detection and resolution

 In this approach, deadlocks are allowed to happen. The

scheduler maintains a wait-for-graph for detecting cycle. If
a cycle exists, then one transaction involved in the cycle is
selected (victim) and rolled-back.
 A wait-for-graph is created using the lock table. As soon as
a transaction is blocked, it is added to the graph. When a
chain like: Ti waits for Tj waits for Tk waits for Ti or Tj
occurs, then this creates a cycle.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 18- 27

Database Concurrency Control
Dealing with Deadlock and Starvation
 Deadlock avoidance

 There are many variations of two-phase locking algorithm.

 Some avoid deadlock by not letting the cycle to complete.
 That is as soon as the algorithm discovers that blocking a
transaction is likely to create a cycle, it rolls back the
transaction.
 Wound-Wait and Wait-Die algorithms use timestamps to
avoid deadlocks by rolling-back victim.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 18- 28

Database Concurrency Control
Dealing with Deadlock and Starvation
 Starvation

 Starvation occurs when a particular transaction consistently

waits or restarted and never gets a chance to proceed
further.
 In a deadlock resolution it is possible that the same
transaction may consistently be selected as victim and
rolled-back.
 This limitation is inherent in all priority based scheduling
mechanisms.
 In Wound-Wait scheme a younger transaction may always
be wounded (aborted) by a long running older transaction
which may create starvation.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 18- 29

Database Concurrency Control
Timestamp based concurrency control algorithm
 Timestamp

 A monotonically increasing variable (integer)

indicating the age of an operation or a transaction.
A larger timestamp value indicates a more recent
event or operation.
 Timestamp based algorithm uses timestamp to
serialize the execution of concurrent transactions.

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 18- 30

Database Concurrency Control
Timestamp based concurrency control algorithm
 Basic Timestamp Ordering

 1. Transaction T issues a write_item(X) operation:

a) If read_TS(X) > TS(T) or if write_TS(X) > TS(T), then an
younger transaction has already read the data item so abort
and roll-back T and reject the operation.
b) If the condition in part (a) does not exist, then execute
write_item(X) of T and set write_TS(X) to TS(T).
 2. Transaction T issues a read_item(X) operation:
a) If write_TS(X) > TS(T), then an younger transaction has
already written to the data item so abort and roll-back T and
reject the operation.
b) If write_TS(X)  TS(T), then execute read_item(X) 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- 31
Database Concurrency Control
Timestamp based concurrency control algorithm
 Strict Timestamp Ordering

 1. Transaction T issues a write_item(X) operation:

 If TS(T) > read_TS(X), then delay T until the
transaction T’ that wrote or read X has terminated
(committed or aborted).
 2. Transaction T issues a read_item(X) operation:
 If TS(T) > write_TS(X), then delay T until the
transaction T’ that wrote or read X has terminated
(committed or aborted).

Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 18- 32

Database Concurrency Control
Timestamp based concurrency control algorithm
 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 just ignore the write
operation and continue execution. This is because
the most recent writes counts in case of two
consecutive writes.
 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- 33