Chapter Four

Concurrency Control Techniques

 Outline
1. Introduction
2. Potential problems of concurrency
3. Locking Techniques for Concurrency Control
4. Concurrency Control Based ON Timestamp
Ordering
5. Multi version Concurrency Control Techniques
6. Validation (Optimistic) Concurrency Control
Technique
7. Granularity of Data Items and Multiple
Granularity Locking
Samara University Department of Computer Science 2
 1. Introduction (1)
• If we insist only one transaction can execute at a
time (in serial order), then performance will be
quite poor.
• In a multiprogramming environment where
multiple transactions can be executed
simultaneously, it is highly important to control the
concurrency of transactions.
• We have concurrency control protocols to ensure
atomicity, isolation, and serializability of
concurrent transactions.

Samara University Department of

3
Computer Science
 Introduction (2)
• Concurrency Control is a method for
controlling or scheduling the operations of
transactions in such a way that concurrent
transactions can be executed safely (i.e.,
without causing the database to reach an
inconsistent state).

Samara University Department of

4
Computer Science
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.

Samara University Department of

5
Computer Science
 Potential problems of concurrency
• The Lost Update Problem
• The Temporary Update (or Dirty Read) Problem
• The Incorrect Summary Problem
• The Lost Update Problem: when two
transactions that access the same database
items have their operations interleaved in a way
that makes the value of some database items
incorrect.
• In table 4.1 the loss of T2’s update is avoided by
preventing T1 from reading the value of balx ,
until after T2’s update has been completed.
Samara University Department of
6
Computer Science
 The lost update problem
Table 4.1

Samara University Department of

7
Computer Science
 The Temporary Update (Dirty Read)
Problem
• A dirty read occurs when a transaction reads a
database object that has been modified by
another not-yet-committed transaction.
• Table 4.2

Samara University Department of

8
Computer Science
The Incorrect Summary Problem (1)
If one transaction is calculating an aggregate
summary function on a number of database items
while other transactions are updating some of these
items, the aggregate function may calculate some
values before they are updated and others after
they are updated.

Samara University Department of

9
Computer Science
The Incorrect Summary Problem(2)

Samara University Department of

10
Computer Science
2. Locking Techniques for concurrency
Control
• Locking is a procedure used to control
concurrent access to data. When one
transaction is accessing the DB a lock may
deny access to another transaction
• A lock is a variable associated with a data item
that describes the status of the item with respect
to possible operations that can be applied to it.
• A locking protocol is a set of rules followed by all
transactions while requesting and releasing locks.
Samara University Department of
11
Computer Science
Types of Locks and System Lock Tables
• A lock is a mechanism to control concurrent
access to a data item
• Two of locking concepts :
1. Binary locks : A lock on a data item can be in
two states; it is either locked or unlocked (or the
binary value 1 or 0,).
2. Shared/exclusive : also known as read/write
locks which provide more general locking
capabilities and are used in practical database
locking schemes.
Samara University Department of
Computer Science 12
 Binary Locks(1)
• A transaction requests access to an item X by
first issuing a lock_item(X) operation. A distinct
lock is associated with each database item X.
• If the value of the lock on X is 1, item X cannot
be accessed by a database operation that
requests the item.
• If the value of the lock on X is 0, the item can be
accessed when requested, and the lock value is
changed to 1. Two operations, lock_item and
unlock_item, are used with binary locking.
Samara University Department of
13
Computer Science
 Binary Locks (2)
• To implement a binary lock, each lock can be
recorded with three fields: <Data_item_name,
LOCK, Locking_transaction> plus a queue for
transactions that are waiting to access the item.
• The system needs to maintain only these
records for the items that are currently locked in
a lock table
• Items not in the lock table are considered to
be unlocked. The DBMS has a lock manager
subsystem to keep track of and control access
to locks.
Samara University Department of
14
Computer Science
 Binary Locks (3)
• If the simple binary locking scheme described here 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.1
4. A transaction T will not issue an unlock_item(X)
operation unless it already holds the lock on item X.
Samara University Department of
15
Computer Science
 Binary Locks (4)
 Example for binary lock
1. T1:LOCK(A)
2. T1:READ(A) A=100
3. T1:A:=A+200 A=300
4. T1:WRITE(A)
5. T1:UNLOCK(A)
6. T2:LOCK(A)
7. T2:READ(A) A=300
8. T2:A:=A+300 A=600
9. T2:WRITE(A) A=600
10. T2:UNLOCK(A)

Samara University Department of

16
Computer Science
 Binary Locks (5)
• 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);
• go to B end;
• unlock_item(X):
• LOCK(X) ← 0; (* unlock the item *)
• if any transactions are waiting
• then wakeup one of the waiting transactions;

Samara University Department of Computer Science 17

 Shared/Exclusive Locks (1)
• It 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 there
are three locking operations: read_lock(X),
write_lock(X), and unlock(X).

Samara University Department of Computer Science 18

 Shared/Exclusive Locks (2)
• 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
• To Implement read-write each record in the lock
table will have four fields: <Data_item_name,
LOCK, No_of_reads, Locking_transaction(s)>

Samara University Department of

19
Computer Science
 Shared/Exclusive Locks (3)
• If LOCK(X)=write-locked, the value of
locking_transaction(s) is a single transaction that
holds the exclusive (write) lock on X.
• If LOCK(X)=read-locked, the value of locking
transaction(s) is a list of one or more
transactions that hold the shared (read) lock on
X.

Samara University Department of

20
Computer Science
Shared/Exclusive Locks (4)
• 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
Samara University Department of
21
Computer Science
 Shared/Exclusive Locks (5)
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.
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.
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.

Samara University Department of

22
Computer Science
 Shared/Exclusive Locks (6)
• 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;
• write_lock(X):
• B: if LOCK(X) = “unlocked”
• then LOCK(X) ← “write-locked” ; else begin
Samara University Department of
23
Computer Science
 Shared/Exclusive Locks (7)
• wait (until LOCK(X) = “unlocked”
• and the lock manager wakes up the transaction);
• go to B end;
• unlock (X):
• if LOCK(X) = “write-locked”
• then begin LOCK(X) ← “unlocked”;
• wakeup one of the waiting transactions, if any end
• else it 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”;
• wakeup one of the waiting transactions, if any ; end; end;
Samara University Department of
24
Computer Science
 Lock Conversions(1)
• A transaction that already holds a lock on item X is
allowed under certain conditions to convert the
lock from one locked state to another.
• For example, it is possible for a transaction T to
issue a read_lock(X) and then later to upgrade the
lock by issuing a write_lock(X) operation.
• If T is the only transaction holding a read lock on X
at the time it issues the write_lock(X) operation, the
lock can be upgraded; otherwise, the transaction
must wait. It is also possible for a transaction T to
issue a write_lock(X) and then later to downgrade
the lock by issuing a read_lock(X) operation.
Samara University Department of
25
Computer Science
 Lock Conversions (2)
• When upgrading and downgrading of locks is
used, the lock table must include transaction
identifiers in the record structure for each lock (in
the locking_transaction(s) field) to store the
information on which transactions hold locks on
the item.
• Using binary locks or read/write locks in
transactions, as described earlier, does not
guarantee serializability of schedules on its own.
• To guarantee serializability, we must follow an
additional protocol concerning the positioning of
locking and unlocking operations in every
transaction.
Samara University Department of
26
Computer Science
 Two-Phase Locking(2PL)(1)
• A transaction follows the 2PL protocol if all locking
operations proceed the first unlock operations in
the transactions. assures serializability.
• Every transaction can be divided in to two phases.
• Phase 1: Growing Phase
- Transaction may obtain locks
- Transaction may not release locks
• Phase 2: Shrinking Phase
- Transaction may release locks
- Transaction may not obtain locks
Samara University Department of
27
Computer Science
 Two-Phase Locking(2PL)(2)
• It is possible to prevent the lost update
problem, uncommitted dependency and
inconsistency analysis problem using 2PL.
• The problem with locking is that it can cause
deadlocks since transaction can wait for locks
on data item

Samara University Department of

28
Computer Science
 Dealing with Deadlock and Starvation (1)
• Deadlock occurs when each transaction T in a
set of two or more transactions is waiting for
some item that is locked by some other
transaction T in the set.
• Fig (a) shows deadlock states and (b) wait for graph

Samara University Department of

29
Computer Science
Dealing with Deadlock and Starvation (2)
• There are three general techniques for handling
deadlocks.
• Timeout: the transaction that has requested a lock
waits for at most a specified period of time
• Deadlock prevention: the DBMS looks ahead to
determine if a transaction would cause deadlock
and never allows dead lock to occur.
• Some of deadlock prevention technique uses the
concept of Time stamp TS(T), which is a unique
identifier assigned to each transaction.

Samara University Department of

30
Computer Science
 Dealing with Deadlock and Starvation (3)
• The timestamps are typically based on the order in
which transactions are started; hence, if transaction
T1 starts before transaction T2, then TS(T1) < TS(T2).
Notice that the older transaction (which starts first)
has the smaller timestamp value.
• Two schemes that prevent deadlock are called wait-
die and wound-wait.
• Wait-die: If TS(Ti) < TS(Tj), then (Ti older than Tj) Ti is
allowed to wait; otherwise (Ti younger than Tj) abort Ti
(Ti dies) and restart it later with the same timestamp.

Samara University Department of

31
Computer Science
Dealing with Deadlock and Starvation (4)

• Wound-wait: If TS(Ti) < TS(Tj), then (Ti older

than Tj) abort Tj (Ti wounds Tj) and restart it
later with the same timestamp; otherwise (Ti
younger than Tj) Ti is allowed to wait.
• Deadlock detection & recovery: DBMS allows
deadlock to occur but recognizes occurrence of
deadlock and break them.

Samara University Department of

32
Computer Science
 Dealing with Deadlock and Starvation (5)
• Recovery technique from deadlock is abortion
• Choice of deadlock victim:
1. Abort the transaction that occur the minimum cost i.e,
How much the transaction has been running, how many
data item has been updated
2. How far to rollback
3. Avoiding starvation. Starvation is another problem of
locking. There is a resource but some transaction can’t
get that resource. This may occur if the waiting scheme
for locked items is unfair, giving priority to some
transactions over others. first-come-first-served queue is
a solution.
Samara University Department of
33
Computer Science
Dealing with Deadlock and Starvation (6)

• Starvation can also occur because of victim

selection if the algorithm selects the same
transaction as victim repeatedly, thus causing it
to abort and never finish execution. The
algorithm can use higher priorities for
transactions that have been aborted multiple
times to avoid this problem.
• The wait-die and wound-wait schemes avoid
starvation, because they restart a transaction
that has been aborted with its same original
timestamp Samara University Department of
34
Computer Science
 Timestamp-Based Protocols (1)
• A timestamp is a unique identifier created by the
DBMS to identify a transaction start time.
• Timestamping: a concurrency control protocol
that orders transactions in such a way that older
transactions with smaller timestamp get priority
in the event of conflict.
• Concurrency control techniques based on
timestamp ordering do not use locks; hence,
deadlocks cannot occur.

Samara University Department of

35
Computer Science
 Timestamp-Based Protocols (2)
• Basic Timestamp Ordering (TO): Whenever some
transaction T tries to issue a read_item(X) or a
write_item(X) operation, the basic TO algorithm
compares the timestamp of T with read_TS(X) and
write_TS(X) to ensure that the timestamp order of
transaction execution is not violated. If this order is
violated, then transaction T is aborted and
resubmitted to the system as a new transaction with
a new timestamp. If T is aborted and rolled back,
any transaction T1 that may have used a value
written by T must also be rolled back.
Samara University Department of
36
Computer Science
 Timestamp-Based Protocols (3)
• With timestamping if a transaction attempts to read
or write a data item, then the read or write is only
allowed to proceed if the last update on that data
item was carried out by another transaction
• In order to assure such behavior, the protocol
maintains for each data Q two timestamp values:
 W-timestamp(Q) is the largest time-stamp of any
transaction that executed write(Q) successfully.
 R-timestamp(Q) is the largest time-stamp of any
transaction that executed read(Q) successfully.

Samara University Department of

37
Computer Science
 Optimistic technique(1)
• Concurrency control techniques we have
discussed so far, a certain degree of checking is
done before a database operation can be
executed.
• optimistic concurrency control techniques is
based on the assumption that conflict is rare and
that it is more efficient to allow transactions to
proceed without imposing delays are ensure
serializability.

Samara University Department of

38
Computer Science
 Optimistic technique (2)
• Execution of transaction is done in three phases.
1. Read and execution phase: Transaction Ti writes
only to temporary local variables
2. Validation phase: Transaction Ti performs a
''validation test‘ to determine if local variables can
be written without violating serializability.
3. Write phase: If Ti is validated, the updates are
applied to the database; otherwise, Ti is rolled back.

Samara University Department of

39
Computer Science
 Optimistic technique (3)
• Each transaction Ti has 3 timestamps
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
• Serializability order is determined by timestamp given
at validation time; this is done to increase concurrency.
Thus, TS(Ti) is given the value of Validation(Ti). This
protocol is useful and gives greater degree of
concurrency if probability of conflicts is low. because
the serializability order is not pre-decided, and
relatively few transactions will have to be rolled back.
Samara University Department of
40
Computer Science
Thank You ...

Samara University Department of

41
Computer Science