---
title: "Lock; distributed CC; deadlock situation"
subject: "Distributed System"
chapter: 8
key: "semester_7/distributed_system:lock-cc-deadlock-situation"
source: https://www.bctengineer.com/q/semester_7/distributed_system/lock-cc-deadlock-situation
site: BCT Engineering
---

# Lock; distributed CC; deadlock situation

Distributed System · Chapter 8: Transaction and Concurrency Control

- Asked in: 2071 Chaitra, 1+4+3 marks
- Video: [L134: Distributed Database Deadlock Handling | Local and Global Wait for Graph | DBMS Lectures](https://www.youtube.com/watch?v=ejiTHeQznwc) — Easy Engineering Classes
- Answer checked by Claude Opus 5.5 (high effort) on 2026-10-14
- Page: https://www.bctengineer.com/q/semester_7/distributed_system/lock-cc-deadlock-situation
- Whole chapter: https://www.bctengineer.com/md/semester_7/distributed_system/chapter-8

## Question

Define lock in concurrency control. How can concurrency be controlled in distributed transactions? What situation does lead to distributed deadlock?

## Short answer

A lock is a variable for concurrent access control with shared/exclusive modes. Distributed concurrency control uses locking (strict 2PL per server), timestamp ordering with global timestamps, or optimistic validation. Distributed deadlock occurs when a wait-for cycle spans multiple servers, e.g., T waits for U on server X and U waits for T on Y.

## Answer

#### Lock
A **lock** is a variable associated with a data item that controls concurrent access. A transaction must obtain the lock before it reads or writes the item, and releases it when finished. Common modes are **read (shared) lock** and **write (exclusive) lock**; several transactions can hold read locks together, but a write lock excludes all others. In **two-phase locking (2PL)** a transaction has a growing phase (acquires locks) followed by a shrinking phase (releases locks, never acquires again). **Strict 2PL** holds all locks until commit or abort, which prevents dirty reads and cascading aborts.

#### Concurrency control in distributed transactions
In a distributed transaction the objects are on different servers, and each server applies its own concurrency control. All servers must agree on the serialization order, otherwise the transactions could be serial at each server but not globally.
- **Locking**: each server locks its own objects. Strict 2PL is used, with locks held until the commit protocol completes. A transaction's locks are held at several servers, so **distributed deadlock** is possible, and the servers must detect or avoid it.
- **Timestamp ordering**: transactions are given globally unique timestamps (a pair of the local clock value and the server id; the servers' clocks are kept roughly synchronized). Each server enforces timestamp rules; if the servers order conflicting transactions the same way, the result is globally serializable. A conflict causes an abort at any server, which aborts the whole transaction.
- **Optimistic**: each server validates the part of the transaction it holds, during the first phase of commit. Validation must produce a consistent order across servers, so a global or ordered validation is needed.

#### Situation leading to distributed deadlock
A **deadlock** is a state in which each transaction in a set is waiting for a lock held by another transaction in the set, so none can proceed. It is shown by a cycle in the **wait-for graph** (nodes are transactions, an edge T → U means T waits for U).

A **distributed deadlock** occurs when the wait-for cycle spans several servers. Each server sees only a part of the graph (a local wait-for graph without a local cycle), but the global graph has a cycle.

Example: T holds a lock on A at server X, and U holds a lock on B at server Y. T now requests B at Y (so T waits for U), and U requests A at X (so U waits for T).

```text
Server X: U -> T  (U waits for T on A)
Server Y: T -> U  (T waits for U on B)
Global:   T -> U -> T   (cycle = deadlock)
```

## Check yourself

The answer's key points as multiple-choice questions, with the correct option and why.

1. What does strict two-phase locking require?
   A. Locks are released as soon as each operation finishes
   B. All locks are held until commit or abort
   C. Locks are acquired only after commit
   D. Only read locks are held
   Answer: B. Holding locks until commit/abort prevents dirty reads and cascading aborts. (Key point: Strict 2PL)

2. Why must all servers in a distributed transaction agree on the serialization order?
   A. To reduce message size
   B. Transactions could be serial at each server but not globally serializable
   C. Because each server has only one object
   D. To avoid using locks
   Answer: B. Local serial order at each server does not guarantee a single global serial order unless they agree. (Key point: Global serialization order)

3. What characterises a distributed deadlock?
   A. A cycle in the local wait-for graph of one server
   B. A wait-for cycle spanning several servers, with no cycle in any local graph
   C. A server crash during commit
   D. Two transactions with the same timestamp
   Answer: B. Each server sees only part of the graph with no local cycle, but the global graph has a cycle. (Key point: Distributed deadlock)

4. T holds A at server X, U holds B at server Y. T requests B and U requests A. What is the global cycle?
   A. T -> U -> T
   B. T -> T
   C. U -> U
   D. No cycle exists
   Answer: A. T waits for U (on B) and U waits for T (on A), forming a cycle T -> U -> T. (Key point: Deadlock example)

## Related in Distributed System

- [Flat/nested transactions; concurrency control](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Aflat-nested-cc-methods) — Distributed System, chapter 8
- [Distributed concurrency control methods](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Adistributed-cc-methods) — Distributed System, chapter 8
- [Flat/nested transactions; optimistic CC](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Aflat-nested-optimistic) — Distributed System, chapter 8
- [Nested transactions; optimistic CC advantages](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Anested-optimistic-advantages) — Distributed System, chapter 8
- [ACP roles; CC methods in transactions](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Aacp-cc-distributed) — Distributed System, chapter 8
- [Lock, deadlock; deadlock avoidance](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Alock-deadlock-avoidance) — Distributed System, chapter 8

## Related in other subjects

- [Lead compensator for satellite position control](https://www.bctengineer.com/question.md?key=semester_6%2Fdigital_control_system%3Alead-compensator-satellite) — Digital Control System, chapter 4