Deadlock Detection in Distributed Databases EDGAR KNAPP Department of Computer Sciences, University of Texas at Austin, Austin, Texas 78712 The problem of deadlock detection in distributed systems has undergone extensive study. An important application relates to distributed database systems. A uniform model in which published algorithms can be cast is given, and the fundamental principles on which distributed deadlock detection schemes are based are presented. These principles represent mechanisms for developing distributed algorithms in general and deadlock detection schemes in particular. In addition, a hierarchy of deadlock models is presented; each model is characterized by the restrictions that are imposed upon the form resource requests can assume. The hierarchy includes the well-known models of resource and communication deadlock. Algorithms are classified according to both the underlying principles and the generality of resource requests they permit. A number of algorithms are discussed in detail, and their complexity in terms of the number of messages employed is compared. The point is made that correctness proofs for such algorithms using operational arguments are cumbersome and error prone and, therefore, that only completely formal proofs are sufficient for demonstrating correctness. Categories and Subject Descriptors: C.2.4 [Computer-Communication Networks]: Distributed Systems-distributed applications; distributed databases; network operating systems; D.4.1 [Operating Systems]: Process Management-concurrency; deadlocks; synchronization; D.4.7 [Operating Systems]: Organization and Design-distributed systems; H.2.4 [Database Management]: Systems-distributed systems; transaction processing General Terms: Algorithms Additional Key Words and Phrases: Deadlock detection, deadlock models, distributed deadlocks INTRODUCTION selection of a so-called victim whose roll- back or abortion breaks the deadlock, and Deadlock detection is an important prob- finally, deadlock resolution itself. This pa- lem in database systems (DBSs), and much per is concerned only with the aspect of attention has been devoted to it in the deadlock detection. Recent developments research community. Generally speaking, a in the area of distributed deadlock detec- deadlock situation is the possible result of tion algorithms are surveyed, with a special competition for resources, such as multiple emphasis on their relation to distributed database transactions requesting exclusive DBSs. The paper introduces a uniform access to data items. framework for the discussion of these al- The deadlock problem has several inter- gorithms. The abstraction achieved this esting components. Among these are dead- way allows us to talk about the algorithms lock prevention, deadlock avoidance, and- in terms of the underlying theoretical con- in connection with deadlock detection-the cepts, instead of just giving a phenomeno- Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. 0 1988 ACM 0360-0300/87/1200-0303 $1.50 ACM Computing Surveys, Vol. 19, No. 4, December 1987 304 l Edgar Knapp CONTENTS developed. Section 2 gives a systematic classification of the models of deadlock as they appear in database applications. A hierarchy of models that gives rise to one INTRODUCTION way of classifying most of the distributed 1. THE DEADLOCK PROBLEM deadlock detection procedures found in the 1.1 A Brief Introduction to Concurrency Control literature is introduced. Another classifi- 1.2 Deadlock in Centralized Systems cation, focusing on the theoretical princi- 1.3 Deadlock in Distributed Databases 1.4 The Database Model ples underlying the work in distributed 1.5 A Specification of the Deadlock Problem deadlock detection schemes, is given in Sec- 1.6 Centralized versus Distributed Deadlock tion 3. A survey of a number of algorithms Detection can be found in Section 4, with examples 2. MODELS OF DEADLOCK 2.1 One-Resource Model from each of the classes introduced in the 2.2 AND Model two previous sections. In the final section 2.3 OR Model the relative merits of the algorithms pre- 2.4 AND-OR Model sented are discussed. The references con- 2.5 (;) Model tain an exhaustive list on the work done in 2.6 Unrestricted Model 3. CLASSES OF DISTRIBUTED DEADLOCK the field of distributed deadlock detection DETECTION ALGORITHMS after 1980. Earlier papers included consti- 3.1 Path-Pushing Algorithms tute “classical articles” related to the 3.2 Edge-Chasing Algorithms subject. 3.3 Diffusing Computations 3.4 Global State Detection 4. A SURVEY OF SELECTED ALGORITHMS 4.1 Obermarck’s Path-Pushing Algorithm 1. THE DEADLOCK PROBLEM 4.2 Mitchell and Merritt’s Algorithm for the Single-Resource Model 1.1 A Brief Introduction to Concurrency 4.3 Chandy and Misra’s Algorithm Control for the AND Model 4.4 Chandy, Misra, and Haas’s Algorithm The deadlock problem in DBSs is part of for the OR Model the area of concurrency control.’ Concur- 4.5 Hermann and Chandy’s Algorithm for the AND-OR Model rency control deals with the problem of 4.6 Brscha and Toueg’s Algorithm coordinating the actions of processes that for the (;) Model operate in parallel, access shared data, and 5. DISCUSSION therefore potentially interfere with each ACKNOWLEDGMENTS other. The object of study is an abstraction REFERENCES BIBLIOGRAPHY (model) of many different types of infor- mation systems. The main component of this model is the transaction. Informally, a transaction is an execution of a program that accesses a shared database. In our logical description of the workings of the model transactions are characterized by a algorithms (cf. Elmagarmid [1986]). sequence of operations, for example, R(x) The paper is organized as follows. Sec- denoting the operation of reading some tion 1 focuses on the relationship between data item x from the database and W(X) the deadlock problem and DBSs. For the standing for the operation of assigning a benefit of those readers not familiar with new value to data item x in the database. the necessary database terminology, a brief When two or more transactions execute outline of the relevant concepts is given. concurrently, their database operations ex- For a more thorough treatment of this ma- ecute in an interleaved fashion. That is, terial, the reader is referred to recent operations from one transaction may exe- texts on concurrency control, for example, cute in between two operations of another Bernstein et al. [1987] and Papadimitriou transaction. This interleaving can cause [1987]. Next, a database model is pre- sented, and a specification of the deadlock 1 Part of Section 1.1 follows the introductory chapter detection problem in terms of this model is of Bernstein et al. 11987 1. ACM Computing Surveys, Vol. 19, No. 4, December 1987 Deadlock Detection in Distributed Databases 305 transactions to behave incorrectly or inter- Hence both transactions are blocked, wait- fere, thereby leading to an inconsistent ing for each other: a deadlock situation. database state. Informally, deadlock in a DBS can be The part of the DBS that controls the defined as “a situation in which each trans- relative order in which database operations action in a set of transactions is blocked requested by transactions execute is called waiting for another transaction in the set, the scheduler. The scheduler determines and therefore none will become unblocked the interleaving of database operations unless there is external intervention” (cf. such that the consistency of the database Bernstein et al. [1987]). is preserved. A particular such interleaving Even though some concurrency control of database operations is called a schedule. protocols are provably deadlock free (e.g., As an example, consider the schedule conservative 2PL,3 tree locking), most given below involving two transactions tl known protocols are vulnerable to dead- and t2 and two entities x and y (the notation lock. We next look at a number of other follows Bernstein et al. [1987] and Papa- ways in which deadlock can arise in a DBS. dimitriou [ 19871): Let us consider the case of multiversion schedulers, where each write operation on t1: R(x) W(Y) some data item produces a new version of tz : R(Y) W(x) this item, and each read operation of an This schedule formalizes the following se- item is mapped to some version of this item quence of database operations: transaction that was written previously. In the proto- tl first reads database item x, then t2 reads col for a multiversion-view-serializability y, followed by tl writing y, and finally t2 (MV-VSR) scheduler, the last step of a writing x. transaction is treated in a special way to ensure that at most one uncommitted 1.2 Deadlock in Centralized Systems version exists for any data item in the database. If such a scheduler is given the There are many different known strategies schedule of the previous example, the for schedulers for solving the problem of following happens: concurrent accesses without compromising database consistency. A detailed discussion tl reads x, of these strategies is beyond the scope of t:! reads y, this paper. The interested reader is referred tl waits for t2 to finish (commit), to Bernstein et al. [1987] and Papadimi- t2 waits for tl to finish (commit), triou [ 1987 1. The most popular of these strategies is and, again, the result is deadlock. so-called locking. Locking is the strategy of Lock conversion is a concurrency control reserving access rights (locks) that prevent technique that allows upgrading of a lock other transactions from obtaining certain to a stronger lock type, such as converting other (conflicting) locks. a read lock on a data item into a write lock As an example, consider a protocol called on the same item.