--- title: "Distributed concurrency control methods" subject: "Distributed System" chapter: 8 key: "semester_7/distributed_system:distributed-cc-methods" source: https://www.bctengineer.com/q/semester_7/distributed_system/distributed-cc-methods site: BCT Engineering --- # Distributed concurrency control methods Distributed System · Chapter 8: Transaction and Concurrency Control - Asked in: Model question - Video: [Concurrency Control in Distributed System](https://www.youtube.com/watch?v=37GNuOlsSuY) — Norman Dias - Answer checked by Claude Opus 5.5 (high effort) on 2026-10-14 - Page: https://www.bctengineer.com/q/semester_7/distributed_system/distributed-cc-methods - Whole chapter: https://www.bctengineer.com/md/semester_7/distributed_system/chapter-8 ## Question Define distributed concurrency control. Explain the different methods of concurrency control in distributed transactions. Also make a comparison among them. ## Short answer Distributed concurrency control ensures globally serializable ordering across servers. Methods: strict two-phase locking holds locks until commit, risking distributed deadlock; timestamp ordering uses globally unique timestamps and aborts on conflict; optimistic control validates at commit, best for low contention. Locking is pessimistic, timestamp avoids deadlocks but aborts, optimistic wastes work under high conflict. ## Answer #### Distributed concurrency control **Distributed concurrency control** is the control of concurrent execution of transactions that access objects on several servers, so that the transactions are serially equivalent **at every server** and the **same order** is used by all servers (global serializability), while atomic commit makes the outcome consistent. #### Methods 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. #### Locking in detail 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. #### Comparison | Point | Locking | Timestamp ordering | Optimistic | |---|---|---|---| | Approach | Pessimistic; prevent conflicts | Order by timestamps | Detect conflicts at the end | | Conflict handling | Wait | Abort and restart | Abort and restart | | Deadlock | Possible | None | None | | Overhead | Lock table, lock calls | Timestamps on objects | Read/write sets, validation | | Best when | Many conflicts | Moderate conflicts | Few conflicts, mostly reads | | Weakness | Reduced concurrency, deadlock | Many restarts, cascading aborts | Wasted work under heavy conflict | In distributed locking, deadlock must be handled globally (distributed deadlock detection); in timestamp ordering, globally unique timestamps are needed; in optimistic control, validation occurs at all servers in the commit phase. ## Check yourself The answer's key points as multiple-choice questions, with the correct option and why. 1. What extra requirement exists for distributed concurrency control beyond serial equivalence at each server? A. Every server must use locking B. All servers must serialize conflicting transactions in the same order C. Only one server may be active D. Timestamps must be avoided Answer: B. Otherwise transactions could be serial at each server but not globally. (Key point: Global serializability) 2. Why is distributed deadlock a concern in distributed locking? A. Timestamps are not used B. A transaction's locks are held at several servers, so a wait cycle can span servers C. Read locks exclude each other D. Servers have no clocks Answer: B. Cycles of waits across servers need global detection or avoidance. (Key point: Distributed deadlock) 3. How are globally unique timestamps formed in distributed timestamp ordering? A. Server id combined with a local clock value B. A random number per message C. The size of the transaction D. The name of the client Answer: A. Server id plus local clock value gives unique, roughly synchronized timestamps. (Key point: Global timestamps) 4. When does each server validate its part in distributed optimistic control? A. During the working phase B. During the first phase of the commit protocol C. After the update phase D. Never; the client validates Answer: B. Validation is part of commit, and servers must validate in a consistent order. (Key point: Distributed optimistic) ## Close variants set in other exams - [Concurrency control methods compared](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Acc-methods-compare) — Distributed System, chapter 8 ## 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 - [Concurrency control goals and mechanisms](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Acc-goals-mechanisms) — Distributed System, chapter 8 - [Event notification among distributed objects](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Aevent-notification-architecture) — Distributed System, chapter 2 - [Distributed and nested distributed transactions](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Adistributed-transaction-nested) — 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