Concurrency Control Techniques

Outline
 Databases Concurrency Control
1. Purpose of Concurrency Control
2. Two-Phase locking
3. Time-Stamp Based
4. Multi-Version Concurrency Control
5. Validation Based Concurrency Control
6. Granularity of Data Items and Multiple
Granularity Locking

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.
 To ensure serializability

 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 the other
transaction is rolled-back or waits.

Slide 18- 3
Database Concurrency Control:
Types of Locks
 Binary Locks: A binary lock can have two states or values:
Locked and Unlocked(1 and 0 for simplicity)
 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.

Slide 18- 4
Database Concurrency Control:
Types of Locks
Binary Locks:Lock
 The following code performs the lock operation:

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;

Slide 18- 5
Database Concurrency Control:
Types of Locks
Binary Locks : Unlock
 The following code performs the unlock operation:

LOCK (X)  0 (*unlock the item*)

if any transactions are waiting then
wake up one of the waiting the transactions;

Slide 18- 6
Database Concurrency Control:
Binary Locking Scheme

Slide 18- 7
Shared/Exclusive Locks:

Slide 18- 8
Database Concurrency Control:
Shared/Exclusive Lock

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

Slide 18- 9
Database Concurrency Control:Lock
Manager
 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
Slide 18- 10
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.

Slide 18- 11
Database Concurrency Control
Two-Phase Locking Techniques: Essential components
 The following code performs the read operation:

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

Slide 18- 13
Database Concurrency Control
Two-Phase Locking Techniques: Essential components

The following code performs the unlock operation:

Slide 18- 14
Database Concurrency Control
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)
convert write-lock (X) to read-lock (X)

Slide 18- 15
Database Concurrency Control:
Guaranteeing Serializability by Locking

T1 T2 Result
read_lock (Y); read_lock (X); Initial values: X=20; Y=30
read_item (Y); read_item (X); Result of serial execution
unlock (Y); unlock (X); T1 followed by T2
write_lock (X); Write_lock (Y); X=50, Y=80.
read_item (X); read_item (Y); Result of serial execution
X:=X+Y; Y:=X+Y; T2 followed by T1
write_item (X); write_item (Y); X=70, Y=50
unlock (X); unlock (Y);

Slide 18- 16
Database Concurrency Control:
Guaranteeing Serializability by Locking
Locking Techniques: The algorithm

T1 T2 Result
read_lock (Y); X=50; Y=50
read_item (Y); Nonserializable because it.
unlock (Y); violated two-phase policy.
read_lock (X);
read_item (X);
Time unlock (X);
write_lock (Y);
read_item (Y);
Y:=X+Y;
write_item (Y);
unlock (Y);
write_lock (X);
read_item (X);
X:=X+Y;
write_item (X);
unlock (X);

Slide 18- 17
Database Concurrency Control:
Guaranteeing Serializability by Locking

Slide 18- 18
Database Concurrency Control
Two-Phase Locking Techniques: The algorithm
 Two Phases:
 (a) Locking (Growing)

 (b) Unlocking (Shrinking).

 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.

Slide 18- 19
Database Concurrency Control
Two-Phase Locking Techniques: The algorithm

T’1 T’2
read_lock (Y); read_lock (X); T1 and T2 follow two-phase
read_item (Y); read_item (X); policy but they are subject to
write_lock (X); Write_lock (Y); deadlock, which must be
unlock (Y); unlock (X); dealt with.
read_item (X); read_item (Y);
X:=X+Y; Y:=X+Y;
write_item (X); write_item (Y);
unlock (X); unlock (Y);

Slide 18- 20
Two Phase Locking Problems:

Slide 18- 21
Database Concurrency Control
Deadlock:

Dealing with Deadlock


Deadlock
T’1 T’2
read_lock (Y); T1 and T2 did follow two-phase
read_item (Y); policy but they are deadlock
read_lock (X);
read_item (X);
write_lock (X);
(waits for X) write_lock (Y);
(waits for Y)


Deadlock (T’1 and T’2)

Slide 18- 22
Database Concurrency Control

 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.

Slide 18- 23
Database Concurrency Control
 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. One of the transaction
causing the deadlock must be aborted.

Slide 18- 24
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.

Slide 18- 25
Variations of Two Phase Locking
Protocol
 Basic:

Transaction locks data items incrementally. This may cause
deadlock which is dealt with.
 Conservative:

Prevents deadlock by locking all desired data items before
transaction begins execution.
 Strict:

In this variation, a transaction T does not release any of its
exclusive (write) locks until after it commits or aborts.
 Rigorous

A more stricter version of Basic algorithm where unlocking is
performed for each type of lock after a transaction terminates
(commits or aborts and rolled-back). This is the most commonly
used two-phase locking algorithm.

Slide 18- 26
Variations of Two Phase Locking
Protocol
 Difference between Strict and Rigorous 2PL:
The former holds write-locks until it commits, whereas
the latter holds all locks(read and write)
 Difference between Conservative and
Rigorous 2PL:

The former must locks all its items before it starts, so
once the transaction starts, it is in its shrinking phase.

The later does not unlock any of its items until it
terminates, so the transaction is in its expanding
phase until it ends.

Slide 18- 27
Time-Stamps to avoid deadlocks
 In this scheme, If a transaction requests a resource
that is locked by another transaction, then the DBMS
simply checks the timestamp of both transactions
and allows the older transaction to wait until the
resource is available for execution.
Suppose, there are two transactions T1 and T2, and
Let the timestamp of any transaction T be TS (T).
Now, If there is a lock on T2 by some other
transaction and T1 is requesting for resources held
by T2, then DBMS performs the following actions:

Slide 18- 28
 Wait and Die: Checks if TS (T1) < TS (T2) – if T1 is the older
transaction and T2 has held some resource, then it allows T1 to wait
until resource is available for execution. That means if a younger
transaction has locked some resource and an older transaction is
waiting for it, then an older transaction is allowed to wait for it till it is
available. If T1 is an older transaction and has held some resource
with it and if T2 is waiting for it, then T2 is killed and restarted later
with random delay but with the same timestamp. i.e. if the older
transaction has held some resource and the younger transaction
waits for the resource, then the younger transaction is killed and
restarted with a very minute delay with the same timestamp.
This scheme allows the older transaction to wait but kills the younger
one.

Slide 18- 29
 Wound Wait Scheme –
In this scheme, if an older transaction requests for
a resource held by a younger transaction, then an
older transaction forces a younger transaction to
kill the transaction and release the resource. The
younger transaction is restarted with a minute
delay but with the same timestamp. If the younger
transaction is requesting a resource that is held by
an older one, then the younger transaction is
asked to wait till the older one releases it.

Slide 18- 30
Difference between Wait-Die and
Wound-Wait

Slide 18- 31
Database Concurrency Control
 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.

Slide 18- 32
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.

Slide 18- 33
Slide 18- 34
Timestamp based concurrency
control

Slide 18- 35
Database Concurrency Control
Timestamp based concurrency control algorithm
 Basic Timestamp Ordering

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


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.

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:

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.

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).

Slide 18- 36
Slide 18- 37
Variation of Basic TimeStamp Ordering:
 Strict Timestamp Ordering: To ensure that
schedules are conflict serializable and strict(for easy
recoverability)
 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).

Slide 18- 38
Database Concurrency Control
Multiversion concurrency control techniques
 This approach maintains a number of versions of a data
item and allocates the right version to a read operation
of a transaction. Thus unlike other mechanisms a read
operation in this mechanism is never rejected.
 Some multiversion concurrency control algorithms use
the concept of view serializabilty rather than conflict
serializability.
 Side effect:

Significantly more storage (RAM and disk) is required to
maintain multiple versions. To check unlimited growth of
versions, a garbage collection is run when some criteria
is satisfied.

Slide 18- 39
Database Concurrency Control
Multiversion Two-Phase Locking Using Certify
Locks
 Concept

 Allow a transaction T’ to read a data item X while it

is write locked by a conflicting transaction T.
 This is accomplished by maintaining two versions
of each data item X where one version must
always have been written by some committed
transaction. This means a write operation always
creates a new version of X.

Slide 18- 40
Database Concurrency Control
Multiversion Two-Phase Locking Using Certify Locks
 Steps
1. X is the committed version of a data item.
2. T creates a second version X’ after obtaining a write lock on X.
3. Other transactions continue to read X.
4. T is ready to commit so it obtains a certify lock on X.
5. The committed version X becomes X’.
6. T releases its certify lock on X, which is X now.
Compatibility tables for

read/write locking scheme read/write/certify locking scheme

Slide 18- 41
Database Concurrency Control
Multiversion Two-Phase Locking Using Certify
Locks
 Note:

 In multiversion 2PL read and write operations from

conflicting transactions can be processed
concurrently.
 This improves concurrency but it may delay
transaction commit because of obtaining certify
locks on all its writes. It avoids cascading abort
but like strict two phase locking scheme conflicting
transactions may get deadlocked.

Slide 18- 42
Database Concurrency Control
Validation (Optimistic) Concurrency Control Schemes
 In this technique only at the time of commit serializability
is checked and transactions are aborted in case of non-
serializable schedules.
 Three phases:
1. Read phase
2. Validation phase
3. Write phase
1. Read phase:
 A transaction can read values of committed data items.
However, updates are applied only to local copies
(versions) of the data items (in database cache).

Slide 18- 43
Database Concurrency Control
Validation (Optimistic) Concurrency Control Schemes
2. Validation phase: Serializability is checked before transactions write
their updates to the database.
 This phase for Ti checks that, for each transaction Tj that is either

committed or is in its validation phase, one of the following

conditions holds:

Tj completes its write phase before Ti starts its read phase.

Ti starts its write phase after Tj completes its write phase, and the
read_set of Ti has no items in common with the write_set of Tj

Both the read_set and write_set of Ti have no items in common with
the write_set of Tj, and Tj completes its read phase.

When validating Ti, the first condition is checked first for each
transaction Tj, since (1) is the simplest condition to check. If (1) is
false then (2) is checked and if (2) is false then (3 ) is checked. If
none of these conditions holds, the validation fails and Ti is aborted.

Slide 18- 44
Database Concurrency Control
Validation (Optimistic) Concurrency Control
Schemes
3. Write phase: On a successful validation
transactions’ updates are applied to the
database; otherwise, transactions are restarted.

Slide 18- 45
Database Concurrency Control
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. A field of a database record (an attribute of a tuple)
2. A database record (a tuple or a relation)
3. A disk block
4. An entire file
5. The entire database

Slide 18- 46
Database Concurrency Control
Granularity of data items and Multiple Granularity
Locking
 The following diagram illustrates a hierarchy of

granularity from coarse (database) to fine

(record).

Slide 18- 47
Slide 18- 48
Slide 18- 49
Multiple Granularity Locking
 Intention-shared (IS): indicates that one or more shared
lock(s) will be requested on some descendent nodes(s).
 Intention-exclusive (IX): indicates that one or more
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 one or more
exclusive lock(s) will be requested on some descendent
nodes(s).

Slide 18- 50
Database Concurrency Control
Granularity of data items and Multiple Granularity
Locking
 These locks are applied using the following

compatibility matrix: Intention-shared (IS

Intention-exclusive (IX)
Shared-intention-exclusive
(SIX)

Slide 18- 51
Database Concurrency Control
Granularity of data items and Multiple Granularity Locking
 The set of rules which must be followed for producing serializable
schedule are

Slide 18- 52
 Database Concurrency Control

Granularity of data items and Multiple Granularity Locking: An example of a serializableSlide

execution
18- 53
Database Concurrency Control
 Granularity of data items and Multiple Granularity Locking: An example
of a serializable execution (continued):
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)

Slide 18- 54
Summary
 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

Slide 18- 55