1. Distributed Transaction Management, Fall 2002Lecture 2 / 23.10. Distributed Deadlock Management Jyrki Nummenmaa http://www.cs.uta.fi/~jyrki/ds01/ jyrki@cs.uta.fi

2. Distributed Transaction Management, Fall 2002Lecture 2 / 23.10. Deadlock - Introdcution n Example: l P1 locks X on time t1. l P2 locks Y on time t2. l P1 attempts to lock Y and gets blocked. l P2 attemts to X on time t4 and gets blocked.

3. Distributed Transaction Management, Fall 2002Lecture 2 / 23.10. Deadlock (continued) n Deadlock can occur in centralised systems. For example: l At the operating system level there can be resource contention between processes l At the transaction processing level there can be data contention between transactions. l In a poorly-designed multithread program, there can be deadlock between threads in the same process.

4. Distributed Transaction Management, Fall 2002Lecture 2 / 23.10. Deadlock ”management” approaches n The approach taken by distributed systems designers to the problem of deadlock depends on the frequency with which it occurs. n Tanenbaum lists four possible strategies l Ignore it. l Detection (and recovery). l Prevention (by statically making deadlock structurally impossible) l Avoidance (by allocating resources carefully). l Although Tanenbaum does not mention it, there is actually a fifth strategy in use out there: Detect local deadlock and ignore global deadlock.

5. Distributed Transaction Management, Fall 2002Lecture 2 / 23.10. Deadlock n Large database systems are typically multi- user systems; that is, they are systems that allow a large number of txns to access the data in a database at the same time. n In principle, it is possible to at any given time allow only a single txn to execute, but this will not give satisfactory performance. n The txn throughput will be too slow because a txn typically spends most of its lifetime waiting for input/output events to compete as it accesses items of data on disk.

6. Distributed Transaction Management, Fall 2002Lecture 2 / 23.10. Local waits-for graphs n Each resource manager can maintain its local `waits- for' graph. n A coordinator maintains a global waits-for graph. When the coordinator detects a deadlock, it selects a victim process and kills it (thereby causing its resource locks to be released), breaking the deadlock. n Problem: The information about changes must be transmitted to the coordinator. The coordinator knows nothing about change information that is in transit. Thus, in practice, many of the deadlocks that it thinks it has detected will be what they call in the trade `phantom deadlocks'.

7. Distributed Transaction Management, Fall 2002Lecture 2 / 23.10. Chandy-Misra-Haas algorithm n When a process has to wait for a resource, a probe message is sent to the holding process. n If the holding process is itself blocked, the message is propagated to the blocking processes. n If the message comes back to the sender, then a cycle has been detected.

8. Distributed Transaction Management, Fall 2002Lecture 2 / 23.10. Using Waits-For Graphs n In principle, it is possible to detect deadlocks by collecting waits-for graphs from the sites and then combining information from them. n The locking data at one site at some time and at some other time at some other site does not necessarily provide a consistent view about the global situation -> this does not work generally. n Global snapshots can be used to solve this problem.

9. Distributed Transaction Management, Fall 2002Lecture 2 / 23.10. Distributed Deadlock Prevention n Some proposed techniques are not feasible in practice, like making a process request all of its resources at the start of execution. n For transaction processing systems with timestamps, the following scheme can be implemented: l When a process blocks, its timestamp is compared to the timestamp of the blocking process. l The blocked process is only allowed to wait if it has a higher timestamp. l This avoids any cyclic dependency.

10. Distributed Transaction Management, Fall 2002Lecture 2 / 23.10. Wound-wait and wound-die n In the wound-wait approach, if an older process requests a lock to an item held by a younger process, it wounds the younger process and effectively kills it. n In the wait-die approach, if a younger process requests a lock to an item held by an older process, the younger process commits suicide. n Both of these approaches kill transactions blindly.

11. Distributed Transaction Management, Fall 2002Lecture 2 / 23.10. Further considerations for wound-wait and wound-die n To reduce the number of unnecessarily aborted transactions, it is possible to use the cautious waiting rule: ”You are always allowed to wait for a process, which is not waiting for another process.” n The aborted processes are re-started with their original timestamps, to prevent livelock. n In livelock, a transaction does not make progress, as it gets aborted over and over again.