- Model question
Distributed concurrency control methods
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.
Define distributed concurrency control. Explain the different methods of concurrency control in distributed transactions. Also make a comparison among them.
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.
✓ Answer checked by Claude Opus 5.5 (high effort)
Related questions
- Concurrency control methods compared · Distributed System, chapter 8
- Flat/nested transactions; concurrency control · Distributed System, chapter 8
- Concurrency control goals and mechanisms · Distributed System, chapter 8
- Event notification among distributed objects · Distributed System, chapter 2
- Distributed and nested distributed transactions · Distributed System, chapter 8
- Flat/nested transactions; optimistic CC · Distributed System, chapter 8
- Nested transactions; optimistic CC advantages · Distributed System, chapter 8