One, Live lock
If the transaction T1 block the data R, the transaction T2 also requests the Block R, so T2 waits. T3 also requested a blockade of R, when T1 released the blockade on R after the system first approved the T3 request, T2 still waits. Then T4 and asked to block R, when T3 released the blockade of R after the system also approved the T4 request, ..., T2 is likely to wait forever, this is the case of a live lock.
A simple way to avoid a live lock is to use a first-come-first-serve strategy.
Two, deadlock
If the transaction T1 blocked the data r1,t2 blocked the data R2, and then the T1 request blockade R2, because T2 has blocked R2, so T1 wait for T2 to release the lock on R2. Then T2 again apply for blockade R1, because T1 has blocked R1,t2 also can only wait T1 release R1 on the lock. So there is T1 waiting for T2, and T2 is waiting for T1 situation, T1 and T2 two transactions can never end, forming a deadlock.
1. Prevention of deadlocks
In the database, a deadlock occurs because two or more transactions have blocked some data objects, and then both request a lock on a data object that has been blocked for other transactions, resulting in a dead wait. Preventing deadlocks is actually about destroying the conditions that create deadlocks. There are usually two ways of preventing deadlocks:
① a blockade law
A blocking law requires that every transaction must be locked at once for all the data to be used, otherwise it cannot continue execution.
Although a blockade method can effectively prevent the occurrence of deadlocks, but there are problems, once will be used in all the data lock, it is bound to expand the scope of the blockade, thereby reducing the concurrency of the system.
② Sequential Blockade method
The sequential blockade method is a pre-set block order for data objects, and all transactions are blocked in this order.
Sequential blocking methods can effectively prevent deadlocks, but there are also problems. The blocking requests for a transaction can be dynamically determined with the execution of the transaction, and it is difficult to determine in advance which objects are to be blocked by each transaction, so it is difficult to impose the blockade in the prescribed order.
It can be seen that the strategy of preventing deadlocks in the operating system is not very suitable for the characteristics of the database, so the DBMS generally adopts the method of diagnosing and unlocking the deadlock in solving the deadlock problem.
2. Diagnosis and release of deadlock
① Timeout method
If a transaction waits longer than the specified time limit, it is assumed that a deadlock has occurred. The time-out method is simple to implement, but its insufficiency is also obvious. One is that it is possible to misjudge a deadlock, and the system will mistakenly assume that a deadlock has occurred because other reasons cause the wait to exceed the time limit. Second, if the time limit is set too long, the deadlock can not be found in time.
② Wait Graph method
The transaction wait graph is a graph g= (t,u). T is the set of nodes, each node represents a running transaction, and U is a collection of edges, and each edge represents the case of a transaction wait. If the T1 waits for T2, then the T1, T2 between the uniform bar has the edge, from the T1 point T2. The transaction wait graph dynamically reflects the wait conditions for all transactions. The concurrency control subsystem periodically (for example, every 1 minutes) detects a transaction wait diagram, which indicates a deadlock in the system if a loop is found in the diagram.
the concurrency control subsystem of DBMS should try to remove the deadlock when it detects the existence of the system. The usual approach is to choose a transaction that deals with the minimum cost of deadlock, undo it, release all the locks held by the transaction, and allow other transactions to continue running. Of course, the data modification operations performed on the revoked firm must be restored.
Bank algorithm the most representative algorithm in the
Avoid deadlock algorithm is the banker algorithm proposed by Dijkstra E.W in 1968:
The algorithm needs to check the applicant's maximum demand for resources, if the system's existing resources can meet the request of the applicant, To satisfy the applicant's request.
This allows the requester to quickly complete its calculations and then release the resources it occupies, thus ensuring that all processes in the system can be completed, thus avoiding deadlocks.
