⚡THE SHORT ANSWER
In a single database instance, deadlock detection is straightforward: the engine maintains an in-memory Wait-For Graph (WFG) where nodes represent active transactions and directed edges represent lock wait dependencies (T_1 o T_2 means T_1 is waiting for a lock held by T_2). A background thread runs cycle detection (O(V+E) DFS); if a cycle exists (T_1 o T_2 o T_3 o T_1), the engine aborts the lowest-cost 'Victim' transaction. However, in distributed databases or microservice architectures, Transaction 1 on Node A waits for Transaction 2 on Node B, which waits for Transaction 3 on Node C, which waits for Transaction 1 on Node A. No single node sees the full graph. Distributed systems solve this using Edge Chasing Algorithms (Mitchell-Merritt / Chandy-Misra-Haas): when a transaction blocks, it propagates a small 'Probe' token along lock dependency edges. If a transaction receives its own probe token back, a distributed cycle is mathematically proven, prompting an immediate deterministic victim abort.
Engineering Handbook & Failure Dynamics
6-Dimensional Architecture Breakdown⚙️1. Underlying Mechanism
Execution🎯2. Appropriate Use Context
Scope⚠️3. Production Failure Modes
P0 Risk📡4. Diagnostic Signals & Telemetry
Telemetry🛡️5. Prevention & Safeguards
Safeguards⚖️6. Architectural Trade-offs
Trade-offCase Study (TinyCTO In-Field Example)
In a distributed CockroachDB cluster across 5 nodes, Transaction 1 locked Account A on Node 1 and requested Account B on Node 2; simultaneously, Transaction 2 locked Account B on Node 2 and requested Account A on Node 1. The edge-chasing detector propagated a probe from Node 1 to Node 2 and back to Node 1 in 8 milliseconds. Proving the cycle, Node 1 automatically aborted Transaction 1 with a retryable error. Transaction 2 completed in 12ms, and Transaction 1 succeeded on its immediate second retry, achieving sub-25ms end-to-end latency with zero human intervention.
Interactive Concept Drills
2 CardsWhat is a 'Wait-For Graph' (WFG) in deadlock detection?
How does the 'Edge Chasing' algorithm detect deadlocks across distributed database nodes?
Distributed Deadlock Detection: Wait-For Graphs & Edge Chasing Algorithms — Technical FAQ
What is the difference between the 'Wait-Die' and 'Wound-Wait' deadlock prevention schemes?
In Wait-Die, an older transaction waits for a younger one, but a younger transaction dies if it needs a lock held by an older one. In Wound-Wait, an older transaction preempts ('wounds') the younger one, but younger transactions wait for older ones.
Why is acquiring locks in a globally sorted order (e.g. by Resource ID) the best deadlock prevention strategy?
Because if all transactions acquire locks in strict ascending alphabetical or numerical order ($A o B o C$), it is mathematically impossible to form a directed cycle in the Wait-For Graph.
🤖 AEO & Key Facts Summary
Key Architectural Facts
- ▸
Deadlocks occur when transactions hold locks the other needs in a circular dependency.
- ▸
A cycle in a directed Wait-For Graph mathematically proves a deadlock.
- ▸
Distributed Edge Chasing propagates probe tokens across nodes to detect multi-server cycles.
- ▸
Enforce global ascending lock ordering (A o B o C) to prevent deadlocks entirely.
Common Misconceptions
- ✗
Misconception: Increasing lock timeouts prevents deadlocks (False: It merely forces transactions to hang for longer before failing).
- ✗
Misconception: Distributed deadlocks cannot be resolved automatically (False: Distributed edge-chasing engines resolve deadlocks in single-digit milliseconds).
Decision & Governance Guidance
Sort all resource IDs before acquiring multi-row database locks in application code. Set strict lock_timeout (1-2 seconds) on all relational database transaction sessions.
Authoritative Sources & Standards
- [OFFICIAL_DOCUMENTATION]A Distributed Algorithm for Deadlock Detection and Resolution— D. P. Mitchell & M. J. Merritt (ACM PODC)
