Concurrency Control

Introduction

Transaction processing systems usually allow multiple transactions to

run concurrently. By allowing multiple transactions to run concurrently
will improve the performance of the system in terms of increased
throughout or improved response time, but this allows causes several
complications with consistency of the data. Ensuring consistency in spite
of concurrent execution of transaction require extra work, which is
performed by the concurrency controller system of DBMS.
Locking Techniques for Concurrency Control
Some of the main techniques used to control concurrent execution of
transactions are based on the concept of locking data items.
What is Lock?
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.
Generally, there is one lock for each data item in the database. Locks are
used as a means of synchronizing the access by concurrent transactions
to the database items.
Types of Locks
Several types of locks are used in concurrency control. To introduce
locking concepts gradually, we first discuss binary locks, which are
simple but restrictive and so are not used in practice. We then discuss
shared/exclusive locks, which provide more general locking capabilities
and are used in practical database locking schemes.
Binary Locks
A binary lock can have two states or values: locked and unlocked.
A distinct lock is associated with each database item A. If the value of
the lock on A is 1, item A cannot be accessed by a database operation
that requests the item. If the value of the lock on A is 0, then item can be
accessed when requested. We refer to the current value of the lock
associated with item A as LOCK(A).There are two operations, lock_item
and unlock_item are used with binary locking. A transaction requests
access to an item A by first issuing a lock_item(A) operation. if
Lock(A)=1, the transaction is forced to wait. If LOCK(A) =0 it is set to 1
(the transaction locks the item) and the transaction is allowed to access
item A. When the transaction is through using the item, it issues an
unlock_item(A) operation, which sets LOCK(A) to 0(unlocks the item)
so that A may be accessed by other transactions. Hence a binary lock
enforces mutual exclusion on the data item.
Rules of Binary Locks
2. A transaction T must issue the operation lock_item(A) before any
read_item(A) or write_item (A) operations are performed in T.
3. A transaction T must issue the operation unlock_item(A) after all
read_item(A) and write_item(A) operations are completed in T.
4. A transaction T will not issue a lock_item(A) operation if it already
holds the lock on item A.
5. A transaction T will not issue an unlock_item(A) operation unless it
already holds the lock on item A.
6. The lock manager module of the DBMS can enforce these rules.
Between the lock_item(A) and unlock_item(A) operations in
transaction T, T is said to hold the lock on item A. At most one
transaction can hold the lock on a particular item. Thus no two
transactions can access the same item concurrently.
Disadvantages of Binary Locks

As discussed earlier, binary locking scheme is too restrictive for

database items, because at most one transaction can hold a lock on a
given item. So, binary locking system cannot be used for practical
purpose.
Share/Exclusive (for Read/Write) Locks
We should allow several transactions to access the same item A if they
all access A for reading purposes only. However, if a transaction is to
write an item A, it must have exclusive access to A. For this purpose, a
different type of lock called a multiple-mode lock is used. In this scheme
there are shared/exclusive or read/write locks are used.
Locking operations
There are three locking operations called read_lock(A), write_lock(A)
and unlock(A) represented as lock-S(A),lock-X(A),unlock(A) (Here, S
indicates shared lock, X indicates exclusive lock)can be performed on a
data item. A lock associated with an item A, LOCK(A), now has three
possible states: “read-locked”, “write-locked,” or “unlocked.” A read-
locked item is also called share-locked item 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.
Example As an illustration consider the simplified banking system. Let A and B be two
accounts that are accessed by transactions T1 and T2. Transaction T1 transfers Rs.50
from account B to account A and is defined as
T1
lock-X(B);
read(B,b) ;
b :=b-50 ;
write(B,b) ;
unlock(B) ;
lock-X(A)
read(A,a);
a:=a+50;
write(A,a);
unlock(A);
Transaction T2 displays the total amount of money in accounts A and B that is, the sum
A+B and is defined as
T2
lock-S(A);
read(A,a);
unlock(A);
lock-S(B);
read(B,b);
unlock(B);
display(a+b);
Suppose that the values of accounts A and B are Rs.100 and Rs.200, respectively. If
these two transactions are executed serially, either in the order T1 and T2 or the order
T2, T1 then transaction T2 will display the value Rs.300. If however, these transactions
are executed concurrently, as shown in Schedule 1. In this case, transaction T2 displays
Rs.250, which is incorrect. The reason for this mistake is that the transaction T1
unlocked data item B too early, as a result of which T2 shows an inconsistent state.
Solution of Inconsistency Problem
Suppose now that unlocking is delayed to the end of the transaction. The transaction
T3 corresponds to T1 with unlocking delayed and is defined as
T3
lock-X(B);
read(B,b) ;
b :=b-50 ;
write(B,b) ;
lock-X(A) ;
read(A,a);
a:=a+50;
write(A,a);
unlock(B);
unlock(A);
Transaction T4 corresponds to T2 with unlocking delayed, and is defined
as
T4
lock-S(A);
read(A,a);
lock-S(B);
read(B,b);
display(a+b);
unlock(A);
unlock(B);
Solution of Starvation Problem
We can avoid starvation problem of transactions by granting locks as follows:
3. If a shared lock is requested, the queue of requests is empty, and the object is not
currently locked in exclusive mode, the lock manager grants the lock and updates
the lock table entry for the object (indicating that the object is locked in shared
mode, and incrementing the number of transactions holding a lock by one).
4. If an exclusive lock is requested, and no transaction currently holds a lock on the
object (which also implies the queue of requests is empty) the lock manager grants
the lock and updates the lock table entry.
5. Otherwise, the requested lock cannot be immediately granted and the lock request
is added to the queue of lock requests for this object. The transaction requesting
the lock is suspended.
6. Note that if T1 has a shared lock on A and T2 requests an exclusive lock, T2
request is queued. Now if T3 requests a shared lock, its request enters the queue
behind that of T2, even though the requested lock is compatible with the lock held
by T1. This rule ensures that T2 does not starve, that is, wait indefinitely while a
stream of other transactions; acquire shared locks and thereby prevent T2 from
getting the exclusive lock that is waiting for.
Problems with two-phase locking protocols
There are two problems with two-phase locking protcol.These are:
1. Deadlock
2. Cascading roll-back
Deadlock
As discussed above, two-phase locking does not ensure freedom from
deadlock. As shown in transaction T3 and T4 are in two phase, but still
there is problem of deadlock.

Cascading roll-back
As shown in partial schedule shown on next page each transaction
observers two-phase locking protocol.
Let us consider, if transaction T5 fails after the read(A,a) operation of
transaction of T7. Then, T5 must be rollback, which results into rollback
of T6 and T7 also. Because, transaction T6 and T7 reads the value of A
modified by transaction T5. Since transaction T5 fails and rollback, it
means that transaction T5 obtain the original value of A and cancels the
modified value of A, but the other transactions T6 and T7 process the
modified value of A and result into inconsistent state of database. In
order to obtain the consistent state of database transactions T6 and T7,
must also rollback and has to start again.

Thus we can say that rollback of T5 results in to rollback T6 and T7 also.

This problem is called as cascading of rollback.
Solutions to avoid cascading of rollbacks
There are two solutions to avoid cascading of rollback. These are:
♦ Strict two phase locking protocol
♦ Rigorous two phase locking protocol
Strict two-phase locking protocol:
The strict two-phase locking protocol, requires, that in addition to
locking being two-phase, all exclusive-mode locks taken by a transaction
must be held until that transaction commits. This requirement ensures
that any data written by an uncommitted transaction are locked in
exclusive mode until the transaction commits, preventing any other
transaction from reading the data.
Rigorous two-phase locking protocol:
It requires all locks to be held until the transaction commits. It can be
easily verified that, with rigorous two-phase locking transactions can be
serialized in the order in which they commit. Most database systems
implement either strict or rigorous two-phase locking.
Conversion of Locks
In order to understand the conversion of locks first consider the following example

T8
read(A1,a1);
read(A2,a2);
…….
read(An,an);

……..
write(A1,a1);
Transaction T9 is defined as
T9
read(A1,a1);
read(A2,a2);
display(a1+a2);
 If we follow two-phase locking protocol the transaction T8 must lock item A1 in
exclusive mode because it has to perform write operation on item A1. The other
transaction T9 which has to just read the value of A1 unable to get shared lock on item
A1 until T8 perform write operation on A1.Since, T8 needs an exclusive lock on A1
only at the end of its execution where it perform write operation on A1 ,it is better if T8
could initially lock A1 in shared mode and then could later change lock to exclusive
mode when it has to perform write operation and we could get more concurrency.
Because, then transaction T8 and T9 could access data item A1 and A2 simultaneously.
This observation leads us to a refinement of the basic two-phase locking protocol, in
which lock conversions are allowed. We shall provide a mechanism for upgrading a
shared lock to an exclusive lock, and downgrading an exclusive lock to a shared lock.
We denote conversion from shared to exclusive modes by upgrade, and from exclusive
to shared by downgrade. Lock conversion cannot be allowed to occur arbitrarily.
Upgrading can take place in only the growing phase, whereas downgrading can take
place in only the shrinking phase. Returning to our example, transactions T8 and T9
can run concurrently under the refined two-phase locking protocol, as shown in the
incomplete schedule given below where only some of the locking instructions are
shown.
♦ When a transaction Ti issues a read(Q) operation. It issue a lock-
S(Q) instruction followed by read(Q) instruction.

♦ When a transaction Ti issues a write(Q) operation, the system

check to see whether Ti already holds a shared locked on data item Q. If
it does the system issue an updgrade(Q) instruction followed by
write(Q) instruction.

♦ Otherwise the system issue a lock-X(Q) instruction followed by

write(Q) instruction.

♦ All lock obtained by the transaction are unlocked after the

transaction commit or abort.
Non two-phase locking protocol
In order to develop those protocols, which are not based on two phase
locking technique, one must have additional information on how each
transaction will access the database. There are various models that differ
in the amount of such information required. There are two types of
protocols which are not be on two phase locking scheme:

♦ Graph Based Protocol

♦ Time stamp-based Protocol