Q1 Deadlock detection, avoidance and prevention 10 marks

DBMS – Deadlock this is from 1st website Do any one which u

easily understand

Deadlock
In a multi-process system, deadlock is an unwanted situation that arises in a shared
resource environment, where a process indefinitely waits for a resource that is held by
another process.
For example, assume a set of transactions {T , T , T , ...,T }. T needs a resource X to complete
0 1 2 n 0

its task. Resource X is held by T , and T is waiting for a resource Y, which is held by T . T is
1 1 2 2

waiting for resource Z, which is held by T . Thus, all the processes wait for each other to
0

release resources. In this situation, none of the processes can finish their task. This situation
is known as a deadlock.
Deadlocks are not healthy for a system. In case a system is stuck in a deadlock, the
transactions involved in the deadlock are either rolled back or restarted.

Deadlock Prevention
To prevent any deadlock situation in the system, the DBMS aggressively inspects all the
operations, where transactions are about to execute. The DBMS inspects the operations and
analyzes if they can create a deadlock situation. If it finds that a deadlock situation might
occur, then that transaction is never allowed to be executed.
There are deadlock prevention schemes that use timestamp ordering mechanism of
transactions in order to predetermine a deadlock situation.
Wait-Die Scheme
In this scheme, if a transaction requests to lock a resource (data item), which is already held
with a conflicting lock by another transaction, then one of the two possibilities may occur −
 If TS(T ) < TS(T ) − that is T , which is requesting a conflicting lock, is older than T −
i j i j

then T is allowed to wait until the data-item is available.

i

 If TS(T ) > TS(t ) − that is T is younger than T − then T dies. T is restarted later with a
i j i j i i

random delay but with the same timestamp.

This scheme allows the older transaction to wait but kills the younger one.
Wound-Wait Scheme
In this scheme, if a transaction requests to lock a resource (data item), which is already held
with conflicting lock by some another transaction, one of the two possibilities may occur −
  If TS(T ) < TS(T ), then T forces T to be rolled back − that is T wounds T . T is restarted
i j i j i j j

later with a random delay but with the same timestamp.

 If TS(T ) > TS(T ), then T is forced to wait until the resource is available.
i j i

This scheme, allows the younger transaction to wait; but when an older transaction requests
an item held by a younger one, the older transaction forces the younger one to abort and
release the item.
In both the cases, the transaction that enters the system at a later stage is aborted.

Deadlock Avoidance
Aborting a transaction is not always a practical approach. Instead, deadlock avoidance
mechanisms can be used to detect any deadlock situation in advance. Methods like "wait-
for graph" are available but they are suitable for only those systems where transactions are
lightweight having fewer instances of resource. In a bulky system, deadlock prevention
techniques may work well.
Wait-for Graph
This is a simple method available to track if any deadlock situation may arise. For each
transaction entering into the system, a node is created. When a transaction T requests for a i

lock on an item, say X, which is held by some other transaction T , a directed edge is created
j

from T to T . If T releases item X, the edge between them is dropped and T locks the data
i j j i

item.
The system maintains this wait-for graph for every transaction waiting for some data items
held by others. The system keeps checking if there's any cycle in the graph.

Here, we can use any of the two following approaches −

 First, do not allow any request for an item, which is already locked by another
transaction. This is not always feasible and may cause starvation, where a
transaction indefinitely waits for a data item and can never acquire it.
 The second option is to roll back one of the transactions. It is not always feasible to
roll back the younger transaction, as it may be important than the older one. With
 the help of some relative algorithm, a transaction is chosen, which is to be aborted.
This transaction is known as the victim and the process is known as victim selection.

Deadlock in DBMS this is from 2nd or different

website

What is deadlock
In a database management system (DBMS), a deadlock occurs when two or more
transactions are waiting for each other to release resources, such as locks on database
objects, that they need to complete their operations. As a result, none of the transactions
can proceed, leading to a situation where they are stuck or “deadlocked.”
Deadlocks can happen in multi-user environments when two or more transactions are
running concurrently and try to access the same data in a different order. When this
happens, one transaction may hold a lock on a resource that another transaction needs,
while the second transaction may hold a lock on a resource that the first transaction needs.
Both transactions are then blocked, waiting for the other to release the resource they need.
DBMSs often use various techniques to detect and resolve deadlocks automatically. These
techniques include timeout mechanisms, where a transaction is forced to release its locks
after a certain period of time, and deadlock detection algorithms, which periodically scan
the transaction log for deadlock cycles and then choose a transaction to abort to resolve the
deadlock.
It is also possible to prevent deadlocks by careful design of transactions, such as always
acquiring locks in the same order or releasing locks as soon as possible. Proper design of the
database schema and application can also help to minimize the likelihood of deadlocks
In a database, a deadlock is an unwanted situation in which two or more transactions are
waiting indefinitely for one another to give up locks. Deadlock is said to be one of the most
feared complications in DBMS as it brings the whole system to a Halt.
Example – let us understand the concept of Deadlock with an example :
Suppose, Transaction T1 holds a lock on some rows in the Students table and needs to
update some rows in the Grades table. Simultaneously, Transaction T2 holds locks on those
very rows (Which T1 needs to update) in the Grades table but needs to update the rows in
the Student table held by Transaction T1.
Now, the main problem arises. Transaction T1 will wait for transaction T2 to give up the
lock, and similarly, transaction T2 will wait for transaction T1 to give up the lock. As a
consequence, All activity comes to a halt and remains at a standstill forever unless the
DBMS detects the deadlock and aborts one of the transactions.
Deadlock in DBMS

Deadlock Avoidance:
When a database is stuck in a deadlock, It is always better to avoid the deadlock rather than
restarting or aborting the database. The deadlock avoidance method is suitable for smaller
databases whereas the deadlock prevention method is suitable for larger databases.
One method of avoiding deadlock is using application-consistent logic. In the above-given
example, Transactions that access Students and Grades should always access the tables in
the same order. In this way, in the scenario described above, Transaction T1 simply waits for
transaction T2 to release the lock on Grades before it begins. When transaction T2 releases
the lock, Transaction T1 can proceed freely.
Another method for avoiding deadlock is to apply both the row-level locking mechanism and
the READ COMMITTED isolation level. However, It does not guarantee to remove deadlocks
completely.

Deadlxock Detection:
When a transaction waits indefinitely to obtain a lock, The database management system
should detect whether the transaction is involved in a deadlock or not.
Wait-for-graph is one of the methods for detecting the deadlock situation. This method is
suitable for smaller databases. In this method, a graph is drawn based on the transaction
and its lock on the resource. If the graph created has a closed loop or a cycle, then there is a
deadlock.
For the above-mentioned scenario, the Wait-For graph is drawn below:
Deadlock prevention:
For a large database, the deadlock prevention method is suitable. A deadlock can be
prevented if the resources are allocated in such a way that a deadlock never occurs. The
DBMS analyzes the operations whether they can create a deadlock situation or not, If they
do, that transaction is never allowed to be executed.
Deadlock prevention mechanism proposes two schemes:
 Wait-Die Scheme: In this scheme, If a transaction requests a resource that is locked
by another transaction, then the DBMS simply checks the timestamp of both
transactions and allows the older transaction to wait until the resource is available
for execution.
Suppose, there are two transactions T1 and T2, and Let the timestamp of any
transaction T be TS (T). Now, If there is a lock on T2 by some other transaction and
T1 is requesting resources held by T2, then DBMS performs the following actions:
Checks if TS (T1) < TS (T2) – if T1 is the older transaction and T2 has held some resource,
then it allows T1 to wait until resource is available for execution. That means if a younger
transaction has locked some resource and an older transaction is waiting for it, then an
older transaction is allowed to wait for it till it is available. If T1 is an older transaction and
has held some resource with it and if T2 is waiting for it, then T2 is killed and restarted later
with random delay but with the same timestamp. i.e. if the older transaction has held some
resource and the younger transaction waits for the resource, then the younger transaction
is killed and restarted with a very minute delay with the same timestamp.
This scheme allows the older transaction to wait but kills the younger one.

 Wound Wait Scheme: In this scheme, if an older transaction requests for a resource
held by a younger transaction, then an older transaction forces a younger
 transaction to kill the transaction and release the resource. The younger transaction
is restarted with a minute delay but with the same timestamp. If the younger
transaction is requesting a resource that is held by an older one, then the younger
transaction is asked to wait till the older one releases it.
The following table lists the differences between Wait – Die and Wound -Wait scheme
prevention schemes:

Wait – Die Wound -Wait

It is based on a non-preemptive technique. It is based on a preemptive technique.

In this, older transactions must wait for the In this, older transactions never wait
younger one to release its data items. for younger transactions.

The number of aborts and rollbacks is higher in In this, the number of aborts and
these techniques. rollback is lesser.

Q2. What is two phase locking and strick two phase

locking?

1. 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:

1. Upgrading of lock (from S(a) to X (a)) is allowed in growing phase.

2. Downgrading of lock (from X(a) to S(a)) must be done in shrinking

phase.

Example:
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

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

Q3 How does Two phase locking ensure serialization?

Yeh chatGpt sei hai

The two-phase locking (2PL) protocol is a concurrency control mechanism

used in database management systems to ensure the serializability of
transactions. The protocol consists of two phases: the growing phase and
the shrinking phase. Let's discuss how the two-phase locking protocol
ensures serialization:

1. Growing Phase:
 During the growing phase, a transaction can acquire locks but
cannot release any locks.
 When a transaction requests a lock on a data item, it must
wait until the lock is granted. Once granted, the transaction
holds the lock until the end of the transaction.
 The transaction is allowed to acquire multiple locks on
different data items during its execution.
 2. Shrinking Phase:
 Once a transaction releases its first lock, it enters the
shrinking phase.
 In the shrinking phase, the transaction cannot acquire any
new locks but can release locks it currently holds.
 Once a lock is released in the shrinking phase, it cannot
acquire any new locks afterward.

The two-phase locking protocol ensures serialization by enforcing the

following properties:

 Locking is Two-Phased:
 The protocol ensures that transactions go through the growing
phase where locks are acquired and the shrinking phase
where locks are released.
 This two-phased approach helps in preventing issues such as
circular waiting, which can lead to deadlocks.
 Consistency with Serial Execution:
 Because transactions cannot release any locks during the
growing phase, the final set of locks held by a transaction
reflects a point in its execution.
 Releasing locks only starts happening in the shrinking phase,
and by then, no new locks can be acquired.
 Avoidance of Cascading Aborts:
 Once a transaction releases a lock, it cannot acquire any new
locks. This property helps prevent cascading aborts, where the
rollback of one transaction forces the rollback of dependent
transactions.

By adhering to these principles, the two-phase locking protocol ensures

that the schedule of transactions is serializable. A serializable schedule is
one that is equivalent to some serial order of executing the transactions,
and the two-phase locking protocol helps in achieving this equivalence by
controlling the acquisition and release of locks