Lock – Based Concurrency

Control

Ashima Tyagi
Assistant Professor
Computer Science and Engineering
 Introduction

• There are instances where more than one user may attempt to access the
same data item simultaneously, resulting in concurrency.

• As a result, there is a requirement to handle concurrency in order to handle

the concurrent processing of transactions across many databases in the
picture. Lock-based protocol in DBMS is an example of such an approach.
 Potential problems of Concurrency
The four concurrency problems that can occur in the database are:

1. Temporary Update Problem

2. Incorrect Summary Problem
3. Lost Update Problem
4. Unrepeatable Read Problem
 1. Temporary Update
Problem:

Temporary update or dirty read problem

occurs when one transaction updates an
item and fails. But the updated item is used
by another transaction before the item is
changed or reverted back to its last value.
Rollback

In the above example, if transaction 1 fails

for some reason then X will revert back to
its previous value. But transaction 2 has
already read the incorrect value of X. Failure of T1
2. Incorrect Summary Problem:

Consider a situation, where one transaction

is applying the aggregate function on some
records while another transaction is
updating these records. The aggregate
function may calculate some values before
the values have been updated and others
after they are updated.
In the above example, transaction 2 is
calculating the sum of some records while
transaction 1 is updating them. Therefore
the aggregate function may calculate some
values before they have been updated and
others after they have been updated.
 3. Lost Update Problem:

In the lost update problem, an update done

to a data item by a transaction is lost as it is
overwritten by the update done by another
transaction.

In the above example, transaction 2 changes

the value of X but it will get overwritten by
the write commit by transaction 1 on X (not
shown in the image above). Therefore, the
update done by transaction 2 will be lost.
Basically, the write commit done by the last
transaction will overwrite all previous write
commits.
4. Unrepeatable Read Problem:

The unrepeatable problem occurs when

two or more read operations of the same
transaction read different values of the
same variable.

In the above example, once transaction 2

reads the variable X, a write operation in
transaction 1 changes the value of the
variable X. Thus, when another read
operation is performed by transaction 2, it
reads the new value of X which was
updated by transaction 1.
 Introduction to Lock-Based Protocol

• We can define a lock-based protocol in DBMS as a mechanism that is responsible for

preventing a transaction from reading or writing data until the necessary lock is obtained.
• The concurrency problem can be solved by securing or locking a transaction to a specific
user.
• The lock is a variable that specifies which activities are allowed on a certain data item.
 Types of Locks in DBMS

1. Shared Lock
• Shared Locks, which are often denoted as lock-S(), is defined as locks that
provide Read-Only access to the information associated with them.
• Whenever a shared lock is used on a database, it can be read by several users,
but these users who are reading the information or the data items will not have
permission to edit it or make any changes to the data items
Example of Shared Locks: Consider the situation where the value of
variable X equals 50 and there are a total of 2 transactions reading X. If one
transaction wants to change the value of A, another transaction that tries to
read the value will read the incorrect value of the variable X. However, until
it is done with reading, the Shared lock stops it from updating.

When the lock-based protocol in DBMS is applied to the transaction (let's

say T1) discussed above, all the processes listed below occur.

T1 will gain exclusive access to the data item X.

Find out what the current value of data item A is.
The data item will be accessible once the transaction is finished.
2. Exclusive Lock
• Exclusive Lock allows the data item to be read as well as written. This is a one-
time use mode that can't be utilized on the exact data item twice. To obtain X-
lock, the user needs to make use of the lock-x instruction. After finishing the
'write' step, transactions can unlock the data item.
Example of exclusive locks: Consider the instance where the value of a data item X
is equal to 50 and a transaction requires a deduction of 20 from the data item X. By
putting a Y lock on this particular transaction, we can make it possible. As a result,
the exclusive lock prevents any other transaction from reading or writing.
 Lock Compatibility Matrix

A vital point to remember when using Lock-based protocols in Database Management System is
that a Shared Lock can be held by any amount of transactions. On the other hand, an Exclusive
Lock can only be held by one transaction in DBMS, this is because a shared lock only reads data but
does not perform any other activities, whereas an exclusive lock performs read as well as writing
activities.

The figure demonstrates that when two transactions are

involved, and both of these transactions seek to read a
specific data item, the transaction is authorized, and no
conflict occurs; but, in a situation when one transaction
intends to write the data item and another transaction
attempts to read or write simultaneously, the interaction is
rejected.

The two methods outlined below can be used to convert between the locks:

• Conversion from a read lock to a write lock is an upgrade.

• Conversion from a write lock to a read lock is a downgrade.
 Types of Lock-Based Protocols

1. Two-phase Locking Protocol

If Locking as well as the Unlocking can be performed in 2 phases, a transaction is
considered to follow the Two-Phase Locking protocol. The two phases are known as
the growing and shrinking phases.

• Growing Phase: In this phase, we can acquire new locks on data items,
but none of these locks can be released.
• Shrinking Phase: In this phase, the existing locks can be released, but no
new locks can be obtained.
Two-phase locking helps to reduce the amount of concurrency in a schedule
but just like the two sides of a coin two-phase locking has a few cons too.
The protocol raises transaction processing costs and may have unintended
consequences. The likelihood of establishing deadlocks is one bad result.
Steps Transaction T1 Transaction T2
0 Lock–S(A)
1 Lock–S(A)
2 Lock–X(B)
3 — —
4 Unlock(A)
5 Lock–X(C)
6 Unlock(B)
7 Unlock(A)
8 Unlock(C)
9 — —
Here,
Lock–S(A): can’t execute Lock–S(A), since A is locked by transaction T1.
Lock–X(C): can’t execute Lock–X(C), since C is locked by transaction T2.

And, Unlock(A) means unlocking of A.

The same goes for S(A) and S(B).

In the above example, the following phase may happen if the lock conversion is allowed:
• Upgrading of the lock is allowed in the growing phase( from S(A) to X(A) ).
• Downgrading of the lock must be done in the shrinking phase( from X(A) to S(A) ).

The following way shows how locking and unlocking happen in two-phase locking(2PL).

In transaction T1:
Growing phase: from steps 1 to 3
Shrinking phase: from steps 5 to 7
Lock point: at step 3

In transaction T2:
Growing phase: from steps 2 to 6
Shrinking phase: from steps 8 to 9
Lock point: at step 6
2. Strict Two-Phase Locking Protocol
In DBMS, Cascaded rollbacks are avoided with the concept of a Strict Two-Phase
Locking Protocol. This protocol necessitates not only two-phase locking but also
the retention of all exclusive locks until the transaction commits or aborts. The
two-phase is with deadlock.

It is responsible for assuring that if 1 transaction modifies data, there can be no

other transaction that will be able to read it until the first transaction commits. The
majority of database systems use a strict two-phase locking protocol.

The only difference between strict 2PL and 2PL is that strict two-phase locking does
not release a lock after using it. On the other hand, it waits for the whole
transaction to complete, and then it releases all the locks.
3. Rigorous Two-Phase Locking Protocol
Rigorous two-phase locking protocols avoid cascading rollbacks.
In this, all the shared and exclusive locks are only released when the whole
transaction completes.
 Deadlock

In a database, a deadlock is an unwanted situation in which two or more

transactions are waiting indefinitely for one another to give up locks. Deadlock is
said to be one of the most feared complications in DBMS as it brings the whole
system to a Halt.
Example – let us understand the concept of Deadlock with an example :
Suppose, Transaction T1 holds a lock on some rows in the Students table and needs
to update some rows in the Grades table. Simultaneously, Transaction T2 holds
locks on those very rows (Which T1 needs to update) in the Grades table but needs
to update the rows in the Student table held by Transaction T1.

Now, the main problem arises. Transaction T1 will wait for transaction T2 to give up
the lock, and similarly, transaction T2 will wait for transaction T1 to give up the lock.
As a consequence, All activity comes to a halt and remains at a standstill forever
unless the DBMS detects the deadlock and aborts one of the transactions.
Deadlock Detection: When a transaction waits indefinitely to obtain a lock,
The database management system should detect whether the transaction is
involved in a deadlock or not.

Wait-for-graph is one of the methods for detecting the deadlock situation. This
method is suitable for smaller databases. In this method, a graph is drawn
based on the transaction and its lock on the resource. If the graph created has a
closed loop or a cycle, then there is a deadlock.
For the above-mentioned scenario, the Wait-For graph is drawn below:
 Deadlock prevention mechanism proposes two schemes:

Wait – Die Wound -Wait

It is based on a non-preemptive It is based on a preemptive

technique. technique.

In this, older transactions must wait

for the younger one to release its In this, older transactions never wait
data items. for younger transactions.

The number of aborts and rollbacks In this, the number of aborts and
is higher in these techniques. rollback is lesser.
 Starvation
When a transaction must wait an unlimited period for a lock, it is referred to as
starvation. The following are the causes of starvation :

1. When the locked item waiting scheme is not correctly controlled.

2. When a resource leak occurs.
3. The same transaction is repeatedly chosen as a victim.
Let's know how starvation can be prevented. Random process selection for
resource or processor allocation should be avoided since it encourages hunger. The
resource allocation priority scheme should contain ideas like aging, in which a
process' priority rises as it waits longer. This prevents starvation.
Thank You