Showing posts with label Deadlock. Show all posts
Showing posts with label Deadlock. Show all posts

Wait-die deadlock prevention algorithm in Animation

Animated Wait-die deadlock prevention algorithm / Wait-Die scheme explained / How does wait-die scheme prevents deadlock / Wait-die algorithm example in DBMS


Wait-Die Deadlock Prevention Algorithm







For more examples, please visit:

Deadlock prevention algorithms in database


4 necessary conditions for occurrence of deadlock


Four necessary conditions for occurrence of deadlock in databases / Four necessary conditions for deadlock to occur / Necessary and sufficient conditions for deadlock / List and discuss four conditions for deadlock / Necessary conditions that ensures a deadlock occurrence state

 

Necessary conditions for deadlock to occur in database


A deadlock can arise if the following 4 conditions hold simultaneously in a system;

  • Mutual exclusion: At least one resource is held in a non-sharable mode. For example, among transactions if there is any Exclusive lock (Write lock) request, that data item cannot be shared with others.
  • Hold and wait: There is a transaction which acquired and held lock on a data item, and waits for other data item.
  • No preemption: A situation where a transaction releases the locks on data items which it holds only after the successful completion of the transaction. Not on voluntarily.
  • Circular wait: A situation where a transaction say T1 is waiting for another transaction T2 to release lock on some data items, in turn T2 is waiting for another transaction T3 to release lock, and so on.
During transaction processing, if all the said conditions are held then there occurred a deadlock.

Centralized deadlock detection approach in distributed database

Centralized deadlock detection technique / How to handle deadlock detection in distributed database? / False cycle in distributed database deadlock detection / What is false cycle?

 

Centralized deadlock detection approach

This is the technique used in distributed database system to handle deadlock detection. According to this approach, the system maintains one Global wait-for graph in a single chosen site, which is named as deadlock-detection coordinator. The Global wait-for graph is updated during the following conditions;

  • Whenever a new edge is inserted or removed in the local wait-for graphs of any sites.
  • Periodically
  • Whenever the coordinator invokes the detection algorithm.

How does it work?

When the deadlock-detection coordinator starts the deadlock-detection algorithm, it searches for cycles. If the coordinator finds a cycle, then the following will happen;
  • The coordinator selects a victim transaction that need to be rolled back.
  • The coordinator informs about the victim transaction to all the sites in the distributed database.
  • The sites rollback the transaction.


This approach (centralized detection approach) may lead to unnecessary rollbacks due to one of the following; (the main cause is the communication delay.)
1. False cycles -
2. Individual transaction rollback during a deadlock and a victim is chosen – for example; let us assume that a deadlock occurred in a distributed database. Then the coordinator chooses one victim transaction and informs the sites about the victim to rollback. At the same time, because of some other reasons, a transaction Ti rollback itself. Now the whole system performed unnecessary rollbacks.




Deadlock handling in distributed databases




Deadlock Handling in Distributed Database / How do we handle deadlock in distributed database? / Deadlock prevention and detection in distributed database / What is Global Wait-for graph? / Why deadlock handling is difficult in distributed database? / Centralized deadlock detection technique in distributed database


Deadlock Handling in Distributed Database

A Deadlock is a situation in which two or more transactions are waiting for the data items that are held by and to be released by the other transactions. You can find more on the following in the given links;

Deadlock in Distributed Databases

Like in the case of centralized database systems, distributed database systems also prone to Deadlocks. In Distributed Database systems, we need to handle transactions differently. In every site that are part of the distributed database, we have the transaction specific components - transaction coordinators, transaction managers, lock managers, etc. Above all, data might be owned by many sites, or replicated in many sites. Due to these reasons, deadlock handling is bit tough job in Distributed Database.
Deadlock can be handled in two ways;
1. Deadlock prevention – it deals with preventing the deadlock before it occurs. It is harder in centralized database system as it involves more number of rollback and slows down the transactions. In distributed database it would cause more problems because, it rollback more transactions that are happening in more sites (not in a single server but possibly many servers).
2. Deadlock detection – it deals with detecting deadlock if one happened. In centralized database systems, detection is easier compare to prevention. We have handled detection using Wait-for graphs. In the case of distributed database, the main problem is where and how to maintain the Wait-for graphs. 



Deadlock detection technique in distributed database


We have handled deadlock detection in centralized database system using Wait-for graph. The same can be used in distributed database. That is, we can maintain Local wait-for graphs in every site. (How to construct wait-for graph can be referred here). If the local wait-for graph of any site formed a cycle, then we would say that a deadlock has occurred.

On the other hand, no cycles in any of the local wait-for graph does not mean no deadlock has occurred. Let us discuss this point with local wait-for graph examples as shown below;

Figure 1 - Local wait-for graphs of SITE 1 and 2


Figure 1 shows the lock request status for transactions T1, T2, T3 and T4 in a distributed database system. In the local wait-for graph of SITE 1, transaction T2 is waiting for transactions T1 and T3 to finish. In SITE 2, transactions T3 is waiting for T4, and T4 is waiting for T2. From SITE 1 and SITE 2 local wait-for graphs, it is clear that transactions T2 and T3 are involved in both sites.
How it might be happened? For example, transaction T2 which is initiated at SITE 2 may need some data items held by transactions T1 and T3 in SITE 1. Hence, SITE 2 forwards the request to SITE 1. If the transactions are busy, then SITE 1 inserts edges T2 à T1 and T2 à T3 in its local wait-for graph.
As another example, transaction T3 which is initiated at SITE 1 may need data items held by transaction T4 at SITE 2. Hence, SITE 1 forwards the request to SITE 2. Based on the status of T4, SITE 2 inserts an edge T3 à T4 in its local wait-for graph.
You can observe from the local wait-for graphs of SITE 1 and SITE 2, there are no symptoms of cycles. If we merge these two local wait-for graphs into a single wait-for graph, then we would get the graph which is given in Figure 2, below. From Figure 2, it is clear that the union of two local wait-for graphs have formed a cycle, which means deadlock has occurred. This merged wait-for graph is called as Global wait-for graph.

Figure 2 - Global wait-for graph

The approach used to handle deadlock detection in distributed database is,




Wikipedia

Search results

Followers