Concurrency Control

Techniques
Two-Phase Locking Technique
• Concept of two-phase locking
• Types of locks and system lock tables;
• Lock conversion;
• Guaranteeing serializability by two-phase locking;
• Basic, conservative, strict, and rigorous two-phase locking;
• Dealing with deadlock and starvation
What is concurrency?
• Concurrency in terms of databases means allowing multiple users to
access the data contained within a database at the same time.
• If concurrent access is not managed by the Database Management
System (DBMS) so that simultaneous operations don't interfere with
one another problems can occur when various transactions
interleave, resulting in an inconsistent database.
• Concurrency is achieved by the DBMS, which interleaves actions
(reads/writes of DB objects) of various transactions.
• Each transaction must leave the database in a consistent state if the
DB is consistent when the transaction begins.
• Concurrent execution of user programs is essential for good DBMS
performance.
• Because disk accesses are frequent, and relatively slow, it is important to
keep the CPU humming by working on several user programs concurrently.
• Interleaving actions of different user programs can lead to inconsistency:
e.g. check is cleared while account balance is being computed. DBMS ensures
such problems don‘t arise: users can pretend they are using a single-user
system.
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.
Why concurrency control Needed?
• The lost of update problem: problem when two transactions that
access the same database items have their operations interleaved in
such way that value of the data item written by one transaction is
overlapped by another transaction and hence results to the incorrect
value of the database item.
• The dirty read(Temporary update) Problem: problem occur one
transaction updates a database item and then the transaction fails for
some reason.
• The updated item is accessed by another transaction before it’s
changed back to its original value which caused transaction T2 have
dirty value of the data item.
 Cont…

Incorrect summary (Analysis) problem: this problem occurs when one

transaction is calculating an aggregate summary function on a number of
records while other transactions are updating some of these records, the
aggregate function may calculate some values before they are updated
and others after they are updated.
The resulting summary doesn’t reflect the correct result.
Unrepeatable Read Problem: This problem occur when a transaction T
reads an item twice and the item is changed by another transaction T’
between the two reads. Hence, T receives different values for its two
reads of the same item.
LOCK
Lock is a variable associated with data item which gives the status
whether the possible operations can be applied on it or not.
A lock is a mechanism to control concurrent access to a data item
Data items can be locked in two modes:
Exclusive(X) mode:
Data item can be both read as well as written.
X-lock is requested using lock-X instruction.
Shared(S) mode:
Data item can only be read.
S-lock is requested using lock-S instruction.
Lock requests are made to concurrency-control manager.
Transaction can proceed only after request is granted.
Locking Protocol
A locking protocol is a set of rules to be followed by each
transaction (and enforced by the DBMS) in order to ensure that
even though actions of several transactions might be
interleaved, the net effect is identical to executing all
transactions in some serial order.
Lock-Based Concurrency Control:
Locking ensures serializability by requiring that the access to
data item be given in a mutually exclusive manner that is, while
one transaction is accessing a data item, no other transaction
can modify that data item.
Thus, the intent of locking is to ensure serializability by ensuring mutual
exclusion in accessing data items from the point of view of locking a
database can be considered as being made up of a set of data items.
A lock is a variable association with each such data item, manipulating the
value of lock is called as locking.
Locking is done by a subsystem of DBMS called LOCK MANAGER.
There are three modes (types) in which data items can be locked:-
1. Binary Lock
2. Shared Lock
3. Exclusive Lock
Binary Lock:
A Binary Lock can have two states or values locked and unlocked
(1 or 0 for simplicity).
Two operations lock item and unlock item are used with binary locking.
A transaction requests a lock by 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 finishes using item X, it issues an Unlock_Item(X) operation,
which sets Lock (X) to 0, so that X may be accessed by other transactions.
Hence, a binary lock enforces mutual exclusion on the data item.
1. When a binary locking scheme is used, every transaction must
obey the following rules:
The transaction 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) 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.
Shared/execlusive (or Read/Write) Locks
Exclusive Lock:
This mode of locking provides an exclusive use of data item to one
particular transaction.
The exclusive mode of locking is also called an UPDATE or a WRITE lock.
If a transaction T locks a data item Q in an exclusive mode, no other
transaction can access Q, not even to Read Q, until the lock is released by
transaction T.
Shared Lock:
The shared lock is also called as a Read Lock.
• The intention of this mode of locking is to ensure that the data item does
not undergo any modifications while it is locked in this mode.
• This mode allows several transactions to access the same item X if they all
access X for reading purpose only.
• Thus, any number of transactions can concurrently lock and access a data
item in the shared mode, but none of these transactions can modify the
data item.
• A data item locked in the shared mode cannot be locked in the exclusive
mode until the shared lock is released by all the transaction holding the lock.
• A data item locked in the exclusive mode cannot be locked in the shared
mode until the exclusive lock on the data item is released.
IMPLEMENTING LOCK AND
UNLOCK REQUESTS:
1. A transaction requests a shared lock on data item X by executing the Lock_S (X)
instruction.
Similarly, an exclusive lock is requested through the Lock_X (X) instruction.
A data item X can be unlocked via the Unlock (X) instruction.
2. When we use the shared / exclusive locking scheme, the lock manager should
enforce by the rules.
I. A transaction T must issue a operation Lock_S (X) or Lock_X (X) before any Read(X)
operation is performed in T.
II. The transaction T must issue the operation Lock_X (X) before any Write (X) operation is
performed in T.
III. A transaction T must issue the operation Unlock (X) after all Read (X) and Write(X)
operations are completed in T.
IV. A transaction T will not issue a Lock-S (X) operation if it already holds a shared or
exclusive lock on item X.
V. A transaction T will not issue a Lock_X (X) operation if it already holds a shared or
exclusive lock on item X
• Many locking protocols are available which indicate when a
transaction may lock and unlock each of the data items.
• Locking thus restricts the number of possible schedules and most of
the locking protocols allow only conflict serializable schedules.
• The most commonly used locking protocol is Two Phase Locking
Protocol (2PL).
 Two Phase Locking Protocol (2PL):
• The simplest kind of lock is a binary on/off lock. This can
be created by storing a lock bit with each database item.
• If the lock bit is on (e.g. = 1) then the item cannot be
accessed by any transaction either for reading or writing,
if it is off (e.g. = 0) then the item is available.
The Two Phase Locking Protocol ensures Serializability.
• This protocol requires that each transaction issue lock
and unlock requests in two phases:
1. Growing Phase:
A transaction may obtain locks but may not release any lock.
2. Shrinking Phase:
A transaction may release locks but may not obtain any new locks.
A transaction is said to follow Two Phase Locking Protocol if all
locking operations precede the first unlock operation in a transaction.
In other words release of locks on all data items required by the
transaction have been acquired both the phases discussed earlier are
monotonic.
The number of locks are decreasing in the 2nd phase.
Transaction T1 shown in
Two-phase locking (2PL)
• 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.
Eg.
• 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
Deadlock
A system is in a deadlock state if there exists a set of transactions such
that every transaction in the set in waiting for another transaction in
the set.
There exists a set of waiting transactions {T0, T1,…….Tn} such
that T0 is waiting for data item that is held by T1, T1 is waiting
for a data item that is held by T2, Tn-1 is waiting for a data
item that is held by Tn, and Tn is waiting for a data item that is
held by T0.
None of the transactions can make progress in such a situation
Deadlock Prevention:
A deadlock can be prevented by following two commonly used schemes:
1. Wait-Die Scheme:
This scheme is based on a non preemptive technique. When a transaction Ti
requests a data item currently held by Tj, Ti is allowed to wait only if it has a
timestamp smaller than that of Tj (i.e. Ti is older than Tj)
i.e. if the requesting transaction is older than the transaction that holds the
lock on the requesting transaction is allowed to wait.
If the requesting transaction is younger than the transaction that holds the
lock requesting transaction is aborted and rolled back.
For example: suppose that transaction T22, T23 and T24 have timestamps 5,
10 and 15 respectively. If T22 requests a data item held by T23, then T22 will
wait. If T24 requests a data item held by T23, then T24 will be rolled back.
2. Wound-Wait Scheme:
This scheme is based on a preemptive technique and is a counter part to the
wait-die scheme when transaction Ti requests a data item currently held by Tj,
Ti, is allowed to wait only if it has a timestamp larger than that of Tj (i.e. Ti is
younger than Tj).
Otherwise, Tj is rolled back (Tj is wounded by Ti).
i.e. if a younger transaction requests a data item held by an older transaction,
the younger transaction is allowed to wait.
If a younger transaction holds a data item requested by an older one, the
younger transaction is the one that would be aborted and rolled back.
(I.e. younger transaction is wounded by an older transaction and dies).
Considering example given for wait-die scheme, if T22 requests a data item held
by T23, then the data item will be preempted from T23, and T23 will be rolled
back if T24 requests a data item held by T23, and then T24 will wait.
Deadlock detection
A deadlock can be detected by following two common mechanisms:
1. Wait for graph: A deadlock is said to occur when there is a circular
chain of transactions each waiting for the release of the data item held
by the next transaction in the chain. The algorithm to detect a
deadlock is based on the detection of such circular chain in the current
system for Graph. The wait for graph consist of a pair G = (V, E) where V
is a set of vertices which represents all the transactions in the system. E
is the set of edges where each element is an ordered pair Ti  Tj (which
implies that transaction Ti is waiting for transaction Tj to release a data
item that it needs). A deadlock exists in the system if only if the wait for
graph contains a cycle. If there is no cycle there is no deadlock.
2. TIMEOUT MECHANISM:
If transaction has been waiting for too long for a lock we assume it is in
a deadlock. So this cycle is aborted after a fixed interval of time that is
pre set in the system.
Starvation:
when we using locking there is an another problem called starvation. It
occurs when a transaction cannot proceed for a definite period of time
while other transactions in the system continue normally. This may
occur if the waiting scheme for locked item is unfair, giving priority to
some transaction over others. One solution for starvation is to have a
fair waiting scheme, such as using a first-come-first-service queue.
Concurrency Control with Time Stamping Methods
The time stamping approach to scheduling concurrent
transaction assigns a global unique time stamp to each
transaction.
The time stamp value produces an explicit order in which
transactions are submitted to the DBMS.
The time stamp must have following two properties:
• Uniqueness: ensures that no equal time stamp values can exist.
• Monotonicity: ensures that time stamp values always increase.
• All database operations (read and write) within the same transaction
must have the same time stamp.
• The DBMS executes conflicting operations in time stamp order to
ensure serializability of the transaction.
• If two transactions conflict, one often is stopped, rescheduling and
assigned a new time stamps value.
• To implement this scheme we associates with each data item Q to the
timestamp values
W-timestamp(Q):- It denotes the largest time-stamp of any transaction
that execute write(Q) successfully.
R-timestamp(Q):- It denotes the largest time-stamp of any transaction
that executed read(Q) successfully.
• These timestamps are updated whenever a new read(Q) or write(Q)
instruction is executed. The disadvantage of time stamp approach is
that each value stored in the database requires two additional time
stamp fields. One for the last time the field was read and another for
the last update. Time stamping thus increases the memory needs and
the database processing overhead.
• The timestamp-ordering protocol guarantees serializability since all
the arcs in the precedence graph are of the form:
• 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.
• Advantages and Disadvantages of TO protocol:
• TO protocol ensures serializability since the precedence graph is as
follows:
•TS protocol ensures freedom from deadlock that means no transaction ever waits.
•But the schedule may not be recoverable and may not even be cascade- free.
 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:
• an expanding or growing (first) phase, during which new locks on items can be
acquired but none can be released; and
• a 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 Basic, Conservative,
Strict, and Rigorous Two-Phase Locking.
Basic, Conservative, Strict, and Rigorous Two-Phase
Locking.
• There are a number of variations of two-phase locking (2PL). The technique
just described is known as basic 2PL.
• A variation known as conservative 2PL (or static 2PL) requires a transaction
to lock all the items it accesses before the transaction begins execution, by
predeclaring its read-set and write-set.
• the read-set of a transaction is the set of all items that the transaction
reads, and the write-set is the set of all items that it writes.
• If any of the predeclared items needed cannot be locked, the transaction
does not lock any item; instead, it waits until all the items are available for
locking.
• Conservative 2PL is a deadlock-free protocol,
• it is difficult to use in practice because of the need to predeclare the read-
set and writeset, which is not possible in many situations.
• In practice, the most popular variation of 2PL is strict 2PL, which
guarantees strict schedules.
• In this variation, a transaction T does not release any of its exclusive
(write) locks until after it commits or aborts.
• Hence, 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.
• A more restrictive variation of strict 2PL is rigorous 2PL, which also
guarantees strict schedules.
• In this variation, a transaction T does not release any of its locks
(exclusive or shared) until after it commits or aborts, and so it is easier
to implement than strict 2PL.
• Notice the difference between conservative and rigorous 2PL: the
former must
• lock all its items before it starts, so once the transaction starts it is in
its shrinking phase; the latter does not unlock any of its items until
after it terminates (by committing or aborting), so the transaction is in
its expanding phase until it ends.
• In many cases, the concurrency control subsystem itself is responsible for generating
the read_lock and write_lock requests. For example, suppose the system is to
enforce the strict 2PL protocol.
• Then, whenever transaction T issues a read_item(X), the system calls the read_lock(X)
operation on behalf of T.
• If the state of LOCK(X) is write_locked by some other transaction T, the system places
T in the waiting queue for item X; otherwise, it grants the read_lock(X) request and
permits the read_item(X) operation of T to execute. On the other hand, if transaction
T issues a write_item(X), the system calls the write_lock(X) operation on behalf of T.
• If the state of LOCK(X) is write_locked or read_locked by some other transaction T,
the system places T in the waiting queue for item X; if the state of LOCK(X) is
read_locked and T itself is the only transaction holding the read lock on X, the system
upgrades the lock to write_locked and permits the write_item(X) operation by T.
• Finally, if the state of LOCK(X) is unlocked, the system grants the write_lock(X) request
and permits the write_item(X) operation to execute. After each action, the system
must update its lock table appropriately.
Thomas write Rule
• Thomas Write Rule provides the guarantee of serializability order for
the protocol. It improves the Basic Timestamp Ordering Algorithm.
• The basic Thomas write rules are as follows:
• If TS(T) < R_TS(X) then transaction T is aborted and rolled back, and
operation is rejected.
• If TS(T) < W_TS(X) then don't execute the W_item(X) operation of the
transaction and continue processing.
• If neither condition 1 nor condition 2 occurs, then allowed to execute
the WRITE operation by transaction Ti and set W_TS(X) to TS(T).
• If we use the Thomas write rule then some serializable schedule can
be permitted that does not conflict serializable as illustrate by the
schedule in a given figure:
Figure: A Serializable Schedule that is not Conflict Serializable
In the above figure, T1's read and precedes T1's write of the same data item. This
schedule does not conflict serializable.
Thomas write rule checks that T2's write is never seen by any transaction. If we
delete the write operation in transaction T2, then conflict serializable schedule can
be obtained which is shown in below figure.
Figure: A Conflict Serializable Schedule
lock table
• The system needs to maintain only these records for the items that
are currently locked
• in a lock table, which could be organized as a hash file on the item
name.
• 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.
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.
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.
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.
• The use of locks can cause two additional problems:
• deadlock and starvation.
 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.
Hence, each transaction in the set is in a waiting queue, waiting
for one of the other transactions in the set to release the lock on
an item. But because the other transaction is also waiting, it will
never release the lock.
• Deadlock Prevention Protocols. One way to prevent deadlock is
to use a
A simple example is shown in Figure where the two transactions T1and 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.
Timestamp Ordering
• Timestamp ordering concurrency control concept;
• Basic and strict timestamp ordering;
• Thomas’s Write rule
Multiversion Concurrency Control
• Concept of multiversion concurrency control technique;
• Multiversion technique based on timestamp ordering;
• Multiversion locking using certify locks
Multiversion Concurrency Control
Techniques
• Several versions of an item are kept by a system
• Some read operations that would be rejected in other techniques can
be accepted by reading an older version of the item
• Maintains serializability
• More storage is needed
• Multiversion currency control scheme types
• Based on timestamp ordering
• Based on two-phase locking
• Validation and snapshot isolation techniques

Slide 21- 58
Multiversion Concurrency
Control Techniques (cont’d.)
• Multiversion technique based on timestamp ordering
• Two timestamps associated with each version are kept
• read_TS(Xi)
• write_TS(Xi)

Slide 21- 59
Multiversion Concurrency
Control Techniques (cont’d.)
• Multiversion two-phase locking using certify locks
• Three locking modes: read, write, and certify

Figure 21.6 Lock compatibility tables (a) Lock compatibility table for read/write locking
scheme (b) Lock compatibility table for read/write/certify locking scheme
Slide 21- 60
 21.4 Validation (Optimistic) Techniques
and Snapshot Isolation Concurrency
Control
• Optimistic techniques
• Also called validation or certification techniques
• No checking is done while the transaction is executing
• Updates not applied directly to the database until finished transaction is
validated
• All updates applied to local copies of data items
• Validation phase checks whether any of transaction’s updates violate
serializability
• Transaction committed or aborted based on result

Slide 20- 61
Concurrency Control Based on
Snapshot Isolation
• Transaction sees data items based on committed values of the items
in the database snapshot
• Does not see updates that occur after transaction starts
• Read operations do not require read locks
• Write operations require write locks
• Temporary version store keeps track of older versions of updated
items
• Variation: serializable snapshot isolation (SSI)

Slide 20- 62
Validation (Optimistic) Techniques
and Snapshot Isolation Concurrency
Control
• Concept of validation (optimistic) techniques and
• snapshot isolation concurrency control