0% found this document useful (0 votes)
11 views

Concurrency Control

Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
11 views

Concurrency Control

Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 10

Concurrency Control

• Concurrency Control is required for controlling and managing the


concurrent execution of database operations and thus avoiding
the inconsistencies in the database.
Concurrency Control Protocols:
• Concurrency Control Protocol allow concurrent schedules, but
ensure that the schedules are conflict/view serializable, and are
recoverable and may be even cascadeless.
These protocols avoids non-serializable schedules.
• The concurrency control protocols ensure the atomicity,
consistency, isolation, durability and serializability of the
concurrent execution of the database transactions.
These protocols are categorized as:
• Lock Based Concurrency Control Protocol
• Time Stamp Concurrency Control Protocol
• Validation Based Concurrency Control Protocol
Lock Based Protocols: In this type of protocol, any transaction cannot
read or write data until it acquires an appropriate lock on it.
• A lock is a variable associated with a data item that describes the
status of the data item to possible operations that can be applied
to it. They synchronize the access by concurrent transactions to
the database items. It is required in this protocol that all the data
items must be accessed in a mutually exclusive manner.
Types of Lock
• Shared Lock (S): It is also known as Read-only lock. As the name
suggests it can be shared between transactions because while
holding this lock the transaction does not have the permission to
update data on the data item.
S-lock is requested using lock-S instruction.
• Exclusive Lock (X): Data item can be both read as well as written.
This is Exclusive and cannot be held simultaneously on the same
data item. X-lock is requested using lock-X instruction.
• Lock Compatibility Matrix
• A transaction may be granted a lock on an item if
the requested lock is compatible with locks already
held on the item by other transactions.
Any number of transactions can hold shared locks
on an item, but if any transaction holds an
exclusive(X) on the item no other transaction may
hold any lock on the item.
If a lock cannot be granted, the requesting transaction
is made to wait till all incompatible locks held by
other transactions have been released.
Then the lock is granted.
There are four types of lock protocols :
1. Simplistic lock protocol
• It is the simplest way of locking the data in transaction.
• Simplistic lock-based protocols allow all the transactions to get the
lock on the data before insert or delete or update on it.
• It will unlock the data item after completing the transaction.
2. Pre-claiming Lock Protocol
• Pre-claiming Lock Protocols evaluate the transaction to list all the data
items on which they need locks.
• Before initiating an execution of the transaction, it requests DBMS for
all the lock on all those data items.
• If all the locks are granted then this protocol allows the transaction to
begin. When the transaction is completed then it releases all the lock.
• If all the locks are not granted then this
protocol allows the transaction to rolls back and waits until all the locks
are granted.
• 3. Two-phase locking (2PL): A transaction is said to follow the Two-Phase
Locking protocol if Locking and Unlocking can be done in two phases
• Growing Phase: New locks on data items may be acquired but none can
be released.
• Shrinking Phase: Existing locks may be released but no new locks can be
acquired.

• The two-phase locking protocol divides the execution phase of the


transaction into three parts.
• In the first part, when the execution of the transaction starts, it seeks
permission for the lock it requires.
• In the second part, the transaction acquires all the locks. The third phase
is started as soon as the transaction releases its first lock.
• In the third phase, the transaction
cannot demand any new locks. It
only releases the acquired locks.
There are two phases of 2PL:
• Growing phase: In the growing phase, a new lock on
the data item may be acquired by the transaction, but
none can be released.
• Shrinking phase: In the shrinking phase, existing lock
held by the transaction may be released, but no new
locks can be acquired.
• In the below example, if lock conversion is allowed then
the following phase can happen:
• Upgrading of lock (from S(a) to X (a)) is allowed in
growing phase.
• Downgrading of lock (from X(a) to S(a)) must be done in
shrinking phase.
• In the following example, if lock conversion is allowed then the following
phase can happen:
• Upgrading of lock (from S(a) to X (a)) is allowed in growing phase.
• Downgrading of lock (from X(a) to S(a)) must be done in shrinking phase.
The following way shows how unlocking and locking work with 2-PL.
• Transaction T1:
• Growing phase: from step 1-3
• Shrinking phase: from step 5-7
• Lock point: at 3
• Transaction T2:
• Growing phase: from step 2-6
• Shrinking phase: from step 8-9
• Lock point: at 6
• Lock Point
• The Point at which the growing phase ends, i.e., when a transaction takes
the final lock it needs to carry on its work.
4. Strict Two-phase locking (Strict-2PL)
• The first phase of Strict-2PL is similar to 2PL. In the
first phase, after acquiring all the locks, the
transaction continues to execute normally.
• The only difference between 2PL and strict 2PL is
that Strict-2PL does not release a lock after using it.
• Strict-2PL waits until the whole transaction to
commit, and then it releases all the locks at a time.
• Strict-2PL protocol does
not have shrinking phase
of lock release.
• It does not have cascading abort as 2PL does
• Timestamp Ordering Protocol
• The Timestamp Ordering Protocol is used to order the transactions
based on their Timestamps. The order of transaction is nothing but the
ascending order of the transaction creation.
• The priority of the older transaction is higher that's why it executes first.
To determine the timestamp of the transaction, this protocol uses
system time or logical counter.
• The lock-based protocol is used to manage the order between
conflicting pairs among transactions at the execution time. But
Timestamp based protocols start working as soon as a transaction is
created.
• Let's assume there are two transactions T1 and T2. Suppose the
transaction T1 has entered the system at 007 times and transaction T2
has entered the system at 009 times. T1 has the higher priority, so it
executes first as it is entered the system first.
• The timestamp ordering protocol also maintains the timestamp of last
'read' and 'write' operation on a data.
• Basic Timestamp ordering protocol works as follows:
1. Check the following condition whenever a transaction Ti issues a
• Read (X) operation:
• If W_TS(X) >TS(Ti) then the operation is rejected.
• If W_TS(X) <= TS(Ti) then the operation is executed.
• Timestamps of all the data items are updated.
2. Check the following condition whenever a transaction Ti issues a
Write(X) operation:
• If TS(Ti) < R_TS(X) then the operation is rejected.
• If TS(Ti) < W_TS(X) then the operation is rejected and Ti is rolled back
otherwise the operation is executed.
• Where,
TS(TI) denotes the timestamp of the transaction Ti.
R_TS(X) denotes the Read time-stamp of data-item X.
W_TS(X) denotes the Write time-stamp of data-item X.

You might also like