Concurrency Control in Databases.Database management systems

Module-5
Concurrency Control in Databases

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

Two-Phase Locking Techniques for Concurrency Control
• The concept of locking data items is one of the main techniques
used for controlling the concurrent execution of transactions.
• A lock is a variable associated with a data item in the database.
• A lock describes the status of the data item with respect to
possible operations that can be applied to that item.
• A transaction locks an object before using it
• When an object is locked by another transaction, the requesting
transaction must wait

Types of Locks and System Lock Tables
1.Binary Locks
 A binary lock can have two states or values: locked and unlocked (or 1
and 0).
 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
 We refer to the current value (or state) of the lock associated with
item X as lock(X).

 Two operations, lock_item and unlock_item, are used with binary
locking.
 A transaction requests access to an item X by first issuing a lock_item(X)
operation
 If LOCK(X) = 1, the transaction is forced to wait.
 If LOCK(X) = 0, it is set to 1 (the transaction locks the item) and the
transaction is allowed to access item X
 When the transaction is through using the item, it issues an
unlock_item(X) operation, which sets LOCK(X) back to 0 (unlocks the
item) so that X may be accessed by other transactions
 Hence, a binary lock enforces mutual exclusion on the data item.

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;

 In its simplest form, each lock can be a record with three fields:
<Data_item_name, LOCK, Locking_transaction> plus a queue for
transactions that are waiting to access the item
 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.
4. A transaction T will not issue an unlock_item(X) operation unless it
already holds the lock on item X.

2.Shared/Exclusive (or Read/Write) Locks
 binary locking scheme is too restrictive for database items because at
most, one transaction can hold a lock on a given item
 should allow several transactions to access the same item X if they all
access X for reading purposes only
 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—called shared/exclusive or read/write locks—there are
three locking operations: read_lock(X), write_lock(X), and unlock(X).

 A read-locked item is also called shared-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
 Method to implement read/write lock is to
- keep track of the number of transactions that hold a shared (read) lock
on an item in the lock table
- Each record in the lock table will have four fields:
<Data_item_name, LOCK, No_of_reads, Locking_transaction(s)>.
 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.

Concurrency Control in Databases.Database management systems

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

Conversion of Locks
 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

Guaranteeing Serializability by Two-Phase Locking
 A transaction is said to follow the two-phase locking protocol if all locking
operations (read_lock, write_lock) precede the first unlock operation in the
transaction
 Such a transaction can be divided into two phases:
1. Expanding or growing (first) phase, during which new locks on
items can be acquired but none can be released
2. Shrinking (second) phase, during which existing locks can be released
but no new locks can be acquired
 If lock conversion is allowed, then upgrading of locks (from read-locked to
write-locked) must be done during the expanding phase, and downgrading
of locks (from write-locked to read-locked) must be done in the shrinking
phase.

 Transactions T1 and T2 in (a) do not follow the two-phase locking
protocol because the write_lock(X) operation follows the unlock(Y)
operation in T1, and similarly the write_lock(Y) operation follows the
unlock(X) operation in T2
 (b) Results of possible serial schedules of T1 and T2
 (c) A nonserializable schedule S that uses locks

 If we enforce two-phase locking, the transactions can be rewritten as T1’
and T2’ as shown below
 If every transaction in a schedule follows the two-phase locking
protocol, schedule guaranteed to be serializable
 Two-phase locking may limit the amount of concurrency that can occur
in a schedule

Variations of Two-Phase Locking
 Basic 2PL
• Technique described previously
 Conservative (static) 2PL
• Requires a transaction to lock all the items it accesses before the
transaction begins execution by predeclaring read-set and write-set
• Its Deadlock-free protocol
 Strict 2PL
• guarantees strict schedules
• Transaction does not release exclusive locks until after it commits or
aborts
• no other transaction can read or write an item that is written by T
unless T has committed, leading to a strict schedule for recoverability
• Strict 2PL is not deadlock-free

 Rigorous 2PL
• guarantees strict schedules
• Transaction does not release any locks until after it commits or aborts
• easier to implement than strict 2PL

Dealing with Deadlock and Starvation
 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.
 Ex:
Figure : Illustrating the deadlock problem (a) A partial schedule of T1 and
′ T2 that
′
is in a state of deadlock (b) A wait-for graph for the partial schedule in (a)
 The two transactions T1’ and T2_’are deadlocked in a partial schedule; T1’ is
in the waiting queue for X, which is locked by T2’, while T2’ is in the waiting
queue for Y, which is locked by T1’. Meanwhile, neither T1’ nor T2’ nor any
other transaction can access items X and Y

Deadlock prevention protocols
 Transaction timestamp TS(T) is a unique identifier assigned to each transaction
Protocols based on a timestamp
1. Wait-die
2. Wound-wait
• Suppose that transaction Ti tries to lock an item X but is not able to because X is locked
by some other transaction Tj with a conflicting lock. The rules followed by these
schemes are:
• 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.
• 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.

 In wait-die, an older transaction is allowed to wait for a younger
transaction, whereas a younger transaction requesting an item held by
an older transaction is aborted and restarted.
 The wound-wait approach does the opposite: A younger transaction is
allowed to wait for an older one, whereas an older transaction requesting
an item held by a younger transaction preempts the younger transaction
by aborting it.
 It can be shown that these two techniques are deadlock-free, since in
wait-die, transactions only wait for younger transactions so no cycle is
created.
 Similarly, in wound-wait, transactions only wait for older transactions so
no cycle is created.

Protocols that do not use timestamps
1. No waiting (NW) and
2. Cautious waiting (CW) algorithms
No waiting algorithm,
 if a transaction is unable to obtain a lock, it is immediately aborted and then
restarted after a certain time delay without checking whether a deadlock will
actually occur or not.
 no transaction ever waits, so no deadlock will occur
 this scheme can cause transactions to abort and restart needlessly
Cautious waiting
 Try to reduce the number of needless aborts/restarts
 Suppose that transaction Ti tries to lock an item X but is not able to do so
because X is locked by some other transaction Tj with a conflicting lock.
 The cautious waiting rules are as follows:
- If Tj is not blocked (not waiting for some other locked item), then Ti is
blocked and allowed to wait; otherwise abort Ti.
 It can be shown that cautious waiting is deadlock-free, because no transaction
will ever wait for another blocked transaction.

Dealing with Deadlock and Starvation
• 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.

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

• 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.
– One solution for starvation is to have a fair waiting scheme, such as
using a first-come-first-served queue; transactions are enabled to lock
an item in the order in which they originally requested the lock.

Concurrency Control Based on Timestamp Ordering
 Timestamp based algorithm uses timestamp to serialize the execution of
concurrent transactions.
 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).

 Strict Timestamp Ordering
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).
 Thomas’s Write Rule
– If read_TS(X) > TS(T) then abort and roll-back T and reject the operation.
– If write_TS(X) > TS(T), then just ignore the write operation and continue
execution. This is because the most recent writes counts in case of two
consecutive writes.
– If the conditions given in 1 and 2 above do not occur, then execute
write_item(X) of T and set write_TS(X) to TS(T).

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

Multiversion technique based on timestamp ordering
– 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.
– Side effects: 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.

– Assume X1, X2, …, Xn are the version of a data item X created by a
write operation of transactions. With each Xi a read_TS (read
timestamp) and a write_TS (write timestamp) are associated.
– read_TS(Xi): The read timestamp of Xi is the largest of all the
timestamps of transactions that have successfully read version Xi.
– write_TS(Xi): The write timestamp of Xi that wrote the value of
version Xi.
– A new version of Xi is created only by a write operation.

– To ensure serializability, the following two rules are used.
– If transaction T issues write_item (X) and version i of X has the
highest write_TS(Xi) of all versions of X that is also less than or equal
to TS(T), and read _TS(Xi) > TS(T), then abort and roll-back T;
otherwise create a new version Xi and read_TS(X) = write_TS(Xj) =
TS(T).
– If transaction T issues read_item (X), find the version i of X that has
the highest write_TS(Xi) of all versions of X that is also less than or
equal to TS(T), then return the value of Xi to T, and set the value of
read _TS(Xi) to the largest of TS(T) and the current read_TS(Xi).

– To ensure serializability, the following two rules are used.
• If transaction T issues write_item (X) and version i of X has the highest
write_TS(Xi) of all versions of X that is also less than or equal to TS(T),
and read _TS(Xi) > TS(T), then abort and roll-back T; otherwise create a
new version Xi and read_TS(X) = write_TS(Xj) = TS(T).
• If transaction T issues read_item (X), find the version i of X that has the
highest write_TS(Xi) of all versions of X that is also less than or equal to
TS(T), then return the value of Xi to T, and set the value of read _TS(Xi)
to the largest of TS(T) and the current read_TS(Xi).
– Rule 2 guarantees that a read will never be rejected.

Multiversion Two-Phase Locking Using Certify Locks
 In this multiple-mode locking scheme, there are three locking modes for
an item: read, write, and certify
 Hence, the state of LOCK(X) for an item X can be one of read-locked,
writelocked, certify-locked, or unlocked
 We can describe the relationship between read and write locks in the
standard scheme by means of the lock compatibility table shown in
Figure 22.6(a)
 An entry of Yes means that if a transaction T holds the type of lock
specified in the column header on item X and if transaction T_ requests
the type of lock specified in the row header on the same item X, then T_
can obtain the lock because the locking modes are compatible

Figure 22.6: Lock compatibility tables. (a) A compatibility table for read/write locking
scheme. (b) A compatibility table for read/write/certify locking scheme.
 On the other hand, an entry of No in the table indicates that the locks
are not compatible, so T’ must wait until T releases the lock
 The idea behind multiversion 2PL is to allow other transactions T’ to
read an item X while a single transaction T holds a write lock on X
 This is accomplished by allowing two versions for each item X; one
version must always have been written by some committed transaction
 The second version X’ is created when a transaction T acquires a write
lock on the item

Validation (Optimistic) Concurrency Control Techniques
 In optimistic concurrency control techniques, also known as validation
or certification techniques, no checking is done while the transaction is
executing
 In this scheme, updates in the transaction are not applied directly to the
database items until the transaction reaches its end
 During transaction execution, all updates are applied to local copies of
the data items that are kept for the transaction
 At the end of transaction execution, a validation phase checks whether
any of the transaction’s updates violate serializability.

• There are three phases for this concurrency control protocol:
1. Read phase. A transaction can read values of committed data
items from the database. However, updates are applied only to
local copies (versions) of the data items kept in the transaction
workspace.
2. Validation phase. Checking is performed to ensure that
serializability will not be violated if the transaction updates are
applied to the database.
3. Write phase. If the validation phase is successful, the transaction
updates are applied to the database; otherwise, the updates are
discarded and the transaction is restarted.

 The idea behind optimistic concurrency control is to do all the checks at once; hence,
transaction execution proceeds with a minimum of overhead until the validation
phase is reached
 The techniques are called optimistic because they assume that little interference will
occur and hence that there is no need to do checking during transaction execution.
 The validation phase for Ti checks that, for each such transaction Tj that is either
committed or is in its validation phase, one of the following conditions holds:
1. Transaction Tj completes its write phase before Ti starts its read phase.
2. 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.
3. 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 before Ti completes its read
phase.

Granularity of Data Items and Multiple Granularity Locking
 All concurrency control techniques assume that the database is formed
of a number of named data items. A database item could be chosen to be
one of the following:
- A database record
- A field value of a database record
- A disk block
- A whole file
- The whole database
 The granularity can affect the performance of concurrency control and
recovery

Granularity Level Considerations for Locking
 The size of data items is often called the data item granularity.
 Fine granularity refers to small item sizes, whereas coarse granularity refers to
large item sizes
 The larger the data item size is, the lower the degree of concurrency permitted.
 For example, if the data item size is a disk block, a transaction T that needs to
lock a record B must lock the whole disk block X that contains B because a lock
is associated with the whole data item (block). Now, if another transaction S
wants to lock a different record C that happens to reside in the same block X in
a conflicting lock mode, it is forced to wait. If the data item size was a single
record, transaction S would be able to proceed, because it would be locking a
different data item (record).

 The smaller the data item size is, the more the number of items in the
database. Because every item is associated with a lock, the system will
have a larger number of active locks to be handled by the lock manager.
More lock and unlock operations will be performed, causing a higher
overhead
 The best item size depends on the types of transactions involved.
 If a typical transaction accesses a small number of records, it is
advantageous to have the data item granularity be one record
 On the other hand, if a transaction typically accesses many records in
the same file, it may be better to have block or file granularity so that
the transaction will consider all those records as one (or a few) data
items

Multiple Granularity Level Locking
 Since the best granularity size depends on the given transaction, it seems
appropriate that a database system should support multiple levels of
granularity, where the granularity level can be different for various mixes of
transactions
 Figure 22.7 shows a simple granularity hierarchy with a database containing
two files, each file containing several disk pages, and each page containing
several records.
 This can be used to illustrate a multiple granularity level 2PL protocol, where a
lock can be requested at any level
Figure 22.7 A granularity hierarchy for illustrating multiple granularity level locking

 To make multiple granularity level locking practical, additional types of locks,
called intention locks, are needed
 The idea behind intention locks is for a transaction to indicate, along the path
from the root to the desired node, what type of lock (shared or exclusive) it will
require from one of the node’s descendants.
 There are three types of intention locks:
1. Intention-shared (IS) indicates that one or more shared locks will be
requested on some descendant node(s).
2. Intention-exclusive (IX) indicates that one or more exclusive locks will be
requested on some descendant node(s).
3. Shared-intention-exclusive (SIX) indicates that the current node is locked in
shared mode but that one or more exclusive locks will be requested on
some descendant node(s).

 The compatibility table of the three intention locks, and the shared and
exclusive locks, is shown in Figure 22.8.
Figure 22.8: Lock compatibility matrix for multiple granularity locking.

 The multiple granularity locking (MGL) protocol consists of the following rules:
1. The lock compatibility (based on Figure 22.8) must be adhered to.
2. The root of the tree must be locked first, in any mode.
3. A node N can be locked by a transaction T in S or IS mode only if the
parent node N is already locked by transaction T in either IS or IX mode.
4. A node N can be locked by a transaction T in X, IX, or SIX mode only if the
parent of node N is already locked by transaction T in either IX or SIX
mode.
5. A transaction T can lock a node only if it has not unlocked any node (to
enforce the 2PL protocol).
6. A transaction T can unlock a node, N, only if none of the children of node
N are currently locked by T.
 The multiple granularity level protocol is especially suited when processing a
mix of transactions that include
1) short transactions that access only a few items (records or fields) and
2) long transactions that access entire files.

Concurrency Control in Databases.Database management systems

More Related Content

Similar to Concurrency Control in Databases.Database management systems (20)

More from ambikavenkatesh2 (19)

Recently uploaded (20)

Concurrency Control in Databases.Database management systems