Concurrency control is essential for maintaining the consistency and reliability of transactions by synchronizing operations to avoid issues such as lost updates and dirty reads. It utilizes techniques like locking at multiple granularities to manage access to data, while also addressing deadlocks through prevention and detection methods. Deadlock handling can involve rolling back transactions to resolve conflicts, and care must be taken to avoid starvation where a transaction is repeatedly chosen as a victim.

2. Concurrency control ensures the consistency
and reliability properties of transactions.

3. Concurrency control is the problem of synchronizing concurrent
transactions (i.e., order the operations of concurrent transactions) such
that the following two properties are achieved:
– the consistency of the DB is maintained
– the maximum degree of concurrency of operations is achieved
Obviously, the serial execution of a set of transaction achieves
consistency, if each single transaction is consistent
CONCURRENCY CONTROL :

4.  The Lost Update Problem.
This occurs when two transactions that access
the same database items have their operations
interleaved in a way that makes the value of
some database item incorrect.
 The Temporary Update (or Dirty
Read) Problem.
This occurs when one transaction updates a
database item and then the transaction fails for
some reason. The updated item is accessed by
another transaction before it is changed back to
its original value.
Why Concurrency control is
needed :

5. Why Concurrency control is
needed :
 The Incorrect Summary Problem .
If 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.

6. Multiple Granularity
■Allow data items to be of various sizes and define a hierarchy of
data granularities, where the small granularities are nested
within larger ones
■Can be represented graphically as a tree (but don't confuse with
tree-locking protocol)
■When a transaction locks a node in the tree explicitly, it implicitly
locks all the node's descendents in the same mode.
■Granularity of locking (level in tree where locking is done):
 fine granularity (lower in tree): high concurrency, high locking
overhead
 coarse granularity (higher in tree): low locking overhead, low
concurrency

7. Example of Granularity Hierarchy
The highest level in the example hierarchy is the entire database.
The levels below are of type area, file and record in that order.

8. Intention Lock Modes
■In addition to S and X lock modes, there are three additional lock
modes with multiple granularity:
 intention-shared (IS): indicates explicit locking at a lower level of the
tree but only with shared locks.
 intention-exclusive (IX): indicates explicit locking at a lower level with
exclusive or shared locks
 shared and intention-exclusive (SIX): the subtree rooted by that
node is locked explicitly in shared mode and explicit locking is being
done at a lower level with exclusive-mode locks.
■intention locks allow a higher level node to be locked in S or X
mode without having to check all descendent nodes.

9. Compatibility Matrixwith
Intention LockModes
■The compatibility matrix for all lock modes is:
IS IX S S IX X
IS     
IX     
S     
S IX     
X     

10. Multiple Granularity Locking Scheme
■ Transaction Ti can lock a node Q, using the following rules:
1. The lock compatibility matrix must be observed.
2. The root of the tree must be locked first, and may be locked
in any mode.
3. A node Q can be locked by Ti in S or IS mode only if the parent
of Q is currently locked by Ti in either IX or IS
mode.
4. A node Q can be locked by Ti in X, SIX, or IX mode only if the
parent of Q is currently locked by Ti in either IX
or SIX mode.
5. Ti can lock a node only if it has not previously unlocked any node
(that is, Ti is two-phase).
6. Ti can unlock a node Q only if none of the children of Q are
currently locked by Ti.
■Observe that locks are acquired in root-to-leaf order,
whereas they are released in leaf-to-root order.

11. DEADLOCK HANDLING

12. A deadlock is a condition where two or more task are waiting for each
other in order to be finished but none of the task is willing to give up the
resources that the other task need.
For example there exists set of waiting transaction {T0,T1,T2,….,Tn}
such that T0 is waiting for item that T1 holds, and T1 is waiting for item
that T2 holds, and ….,and Tn-1 is waiting for item that Tn holds and Tn
is waiting for item that T0 holds.
In this situation none of the transaction make progress and system
comes to halt.This is known as deadlock.

13. METHODS FOR DEALING DEADLOCK
There are two principle methods for dealing deadlock problem:
1. Deadlock Prevention
2. Deadlock Detection and Recovery
Deadlock prevention is commonly used if the probability that system
would enter deadlock is relatively high otherwise Deadlock Detection
and Recovery is more efficient.

14. DEADLOCK PREVENTION
There are two approaches by which deadlock can be prevented:
1.Wait-Die scheme
2.Wound wait scheme
WAIT-DIE SCHEME:
It is a nonpreemptive technique.When 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 (that is, Ti is older than Tj ). Otherwise, Ti is rolled
back.
WOUND WAIT SCHEME:
It is a preemptive technique.1. 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 (that is, Ti is younger than Tj ). Otherwise, Tj is
rolled back.

15. DEADLOCK DETECTION AND
RECOVERY
DEADLOCK DETECTION
Deadlock can be described in terms of directed graph known as Wait-
For Graph.Graph consists of a pair G=(V,E) where V is the set of
vertices and E is set of edges.For each transaction entering into the
system, a node is created. When a transaction Ti requests for a lock on
an item, say X, which is held by some other transaction Tj, a directed
edge is created from Ti to Tj. If Tj releases item X, the edge between
them is dropped
Wait-For Graph with no cycle:

16. DEADLOCK RECOVERY
The most common solution to recover from deadlock is to roll back one
or more transaction to break the deadlock.Three action to be taken:
1.Selection Of a Victim
Given a set of deadlocked transactions, we must determine which
transaction (or transactions) to roll back to break the deadlock. Selecting
transaction depends on factors like how many data items used,how
many more data to be used,how many transaction to be involved in
rollback.
2.Rollback
Once we have decided that a particular transaction must be
rolled back, we must determine how far this transaction should
be rolled back.

17. Total rollback: It aborts the transaction and restart it.
Partial rollback:It rolls back only as far as necessary to break the lock.
3.Starvation
In a system where the selection of victims is based primarily on cost
factors, it may happen that the same transaction is always picked as a
victim. As a result, this transaction never completes its designated task,
thus there is starvation. We must ensure that a transaction can be picked
as a victim only a (small) finite number of times. The most common
solution is to include the number of rollbacks in the cost factor.