APEX INSTITUTE OF TECHNOLOGY

DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING

Database Management System (21CST-232)

Faculty: Mr. Pramod Vishwakarma (E9758)

Deadlock & Granularity DISCOVER . LEARN . EMPOWER

1
DBMS: Course Objectives
COURSE OBJECTIVES
The Course aims to:
• Understand database system concepts and design databases for different applications
and to acquire the knowledge on DBMS and RDBMS.
• Implement and understand different types of DDL, DML and DCL statements.
• Understand transaction concepts related to databases and recovery/backup
techniques required for the proper storage of data.

By: Pramod Vishwakarma (E9758) 2

COURSE OUTCOMES

On completion of this course, the students shall be able to:-

Understand the database concept, system architecture and role of database
CO1
administrator
CO2 Design database for an organization using relational model
Apply relational algebra and relational calculus to query the database of
CO3
organization
CO4 Implement the package, procedures and triggers
CO5 Understand the concept of transaction processing and concurrency  control

By: Pramod Vishwakarma (E9758) 3

 Deadlocks
• Consider the partial schedule

• Neither T3 nor T4 can make progress — executing lock-S(B) causes T4 to wait for T3 to release
its lock on B, while executing lock-X(A) causes T3 to wait for T4 to release its lock on A.
• Such a situation is called a deadlock.
• To handle a deadlock one of T3 or T4 must be rolled back
and its locks released.
 Deadlocks (Cont.)

• Two-phase locking does not ensure freedom from deadlocks.

• In addition to deadlocks, there is a possibility of starvation.
• Starvation occurs if the concurrency control manager is badly
designed. For example:
• A transaction may be waiting for an X-lock on an item, while a sequence of other
transactions request and are granted an S-lock on the same item.
• The same transaction is repeatedly rolled back due to deadlocks.
• Concurrency control manager can be designed to prevent starvation.
Lock Table
• Dark blue rectangles indicate granted locks; light
blue indicate waiting requests
• Lock table also records the type of lock granted
or requested
• New request is added to the end of the queue of
requests for the data item, and granted if it is
compatible with all earlier locks
• Unlock requests result in the request being
deleted, and later requests are checked to see if
they can now be granted
• If transaction aborts, all waiting or granted
requests of the transaction are deleted
• lock manager may keep a list of locks held
by each transaction, to implement this
efficiently
Deadlock Handling

Deadlock
Deadlock
Detection and
Deadlock Recovery
Avoidance Deadlock
Prevention
Deadlock Avoidance

https://www.quora.com/What-is-wait-die-and-wound-wait-in-DBMS
Deadlock Avoidance
• To decide whether the transaction has to wait or abort
or rollback.
• Wait-Die:
• If requesting transaction is older than the transaction that
holds a lock on requested data item, then the transaction is
allowed to wait until the transaction is completed and release
locks.
• Otherwise requesting transaction is aborted and rollback and
rescheduled.
• Wound-Wait: Opposite of Wait-Die
Deadlock Avoidance: Wound- Wait
• If requesting transaction is older than the transaction
that holds a lock on requested data item, then the
transaction is allowed to wait until the transaction is
completed and release locks.
• Otherwise requesting transaction is aborted and
rollback and rescheduled
 Deadlock Handling
• System is deadlocked if there is a set of transactions such that every
transaction in the set is waiting for another transaction in the set.
• Deadlock prevention protocols ensure that the system will never enter
into a deadlock state. Some prevention strategies :
• Require that each transaction locks all its data items before it begins execution
(predeclaration).
• Impose partial ordering of all data items and require that a transaction can lock
data items only in the order specified by the partial order.
Deadlock prevention (Cont.)
• Timeout-Based Schemes:
• a transaction waits for a lock only for a specified amount of time. If the lock has not been
granted within that time, the transaction is rolled back and restarted,
• Thus, deadlocks are not possible
• simple to implement; but starvation is possible. Also difficult to determine good value of
the timeout interval.
Deadlock Detection
• Deadlocks can be described as a wait-for graph, which consists of a pair G =
(V,E),
• V is a set of vertices (all the transactions in the system)
• E is a set of edges; each element is an ordered pair Ti Tj.
• If Ti  Tj is in E, then there is a directed edge from Ti to Tj, implying that Ti is
waiting for Tj to release a data item.
• When Ti requests a data item currently being held by Tj, then the edge Ti  Tj is
inserted in the wait-for graph. This edge is removed only when Tj is no longer
holding a data item needed by Ti.
• The system is in a deadlock state if and only if the wait-for graph has a cycle.
Must invoke a deadlock-detection algorithm periodically to look for cycles.
Deadlock Detection (Cont.)

Wait-for graph without a cycle Wait-for graph with a cycle

Deadlock Recovery
• Kill the Process – One way is to kill all the process in deadlock or
the second way kill the process one by one, and check after each
if still deadlock exists and do the same till the deadlock is
removed.
• Preemption – The resources that are allocated to the processes
involved in deadlock are taken away(preempted) and are
transferred to other processes. In this way, system may recover
from deadlock as we may change system state.
• Rollback – The OS maintains a database of all different states of
system, a state when the system is not in deadlock is called safe
state. A rollback to previous ‘n’ number of safe states in
iterations can help in the recover.
Deadlock Recovery
• Selection of Victim: The transaction that has just started or
transaction that has not made more updates.
• Rollback – Once selection of victim is done, then it has been
decided whether it is to be total rollback or partial rollback.
• Starvation: To recover from deadlock, if same transaction is
rolled back again and again then that particular transaction may
suffer from starvation means will never get completed. To
avoid starvation, only a finite number of times a transaction
should be selected as a victim.
Multiple Granularity
• It can be defined as hierarchically breaking up the database into blocks which
can be locked.
• The Multiple Granularity protocol enhances concurrency and reduces lock
overhead.
• It maintains the track of what to lock and how to lock.
• It makes easy to decide either to lock a data item or to unlock a data item. This
type of hierarchy can be graphically represented as a tree.
• 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
Example of Granularity Hierarchy

The levels, starting from the coarsest (top) level are

• database
• area
• file
• record
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.
Compatibility Matrix with Intention Lock Modes

• The compatibility matrix for all lock modes is:

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.
• Lock granularity escalation: in case there are too many locks at a particular level,
switch to higher granularity S or X lock
References
• RamezElmasri and Shamkant B. Navathe, “Fundamentals of Database System”, The
Benjamin / Cummings Publishing Co.
• Korth and Silberschatz Abraham, “Database System Concepts”, McGraw Hall.
• C.J.Date, “An Introduction to Database Systems”, Addison Wesley.
• Thomas M. Connolly, Carolyn & E. Begg, “Database Systems: A Practical Approach to
Design, Implementation and Management”, 5/E, University of Paisley, Addison-
Wesley.

By: Pramod Vishwakarma (E9758) 22

THANK YOU

For queries
Email: [email protected]

By: Pramod Vishwakarma (E9758) 23