---
title: "Concurrency control methods compared"
subject: "Distributed System"
chapter: 8
key: "semester_7/distributed_system:cc-methods-compare"
source: https://www.bctengineer.com/q/semester_7/distributed_system/cc-methods-compare
site: BCT Engineering
---

# Concurrency control methods compared

Distributed System · Chapter 8: Transaction and Concurrency Control

- Asked in: Model question
- Video: [Pessimistic concurrency control vs Optimistic concurrency control in Database Systems Explained](https://www.youtube.com/watch?v=I8IlO0hCSgY) — Hussein Nasser
- Answer checked by Claude Opus 5.5 (high effort) on 2026-10-14
- Page: https://www.bctengineer.com/q/semester_7/distributed_system/cc-methods-compare
- Whole chapter: https://www.bctengineer.com/md/semester_7/distributed_system/chapter-8

## Question

Define concurrency control. Explain the different methods of concurrency control. Also make a comparison among them.

## Short answer

Concurrency control coordinates concurrent transactions to achieve serializability. Locking uses shared/exclusive locks with strict two-phase locking; timestamp ordering aborts later transactions to enforce order; optimistic control validates after execution. Locking can cause deadlocks, timestamp ordering incurs restarts, and optimistic excels when conflicts are rare.

## Answer

#### Concurrency control
Concurrency control coordinates concurrent transactions on shared data so that the result is equivalent to a serial execution (serial equivalence), avoiding lost updates, inconsistent retrievals and cascading aborts.

#### Methods
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.

| Lock held \ requested | Read | Write |
|---|---|---|
| None | OK | OK |
| Read | OK | Wait |
| Write | Wait | Wait |

**Timestamp ordering** gives each transaction a unique timestamp when it starts (a Lamport clock or a global timestamp from server id and local clock in a distributed system). Conflicting operations are executed in timestamp order, so the result is equivalent to running transactions serially in timestamp order. No locks are used, so no deadlock.

Each object keeps a **write timestamp** (of the last committed write) and **read timestamps** (of transactions that read it). For a transaction T with timestamp Tc:
- **Write rule**: T's write is allowed only if Tc ≥ the maximum read timestamp of the object and Tc > the write timestamp of the committed version. Otherwise T is aborted (it would invalidate a later read).
- **Read rule**: T's read is allowed if Tc > the write timestamp of the committed version; if a tentative version from an earlier transaction exists, T waits until it commits or aborts. If Tc is smaller than the write timestamp, T is too late and is aborted.

An aborted transaction restarts with a new, later timestamp. Timestamp ordering is deadlock-free, but it causes restarts; keeping multiple versions of objects reduces the number of aborts.

**Optimistic concurrency control** (Kung and Robinson) assumes conflicts are rare, so transactions proceed without locks and are checked for conflicts only when they want to commit. A transaction goes through three phases.
1. **Working phase**: it reads and writes tentative copies of objects (private versions). Reads see the last committed values; no locks are taken. The system records the read set and write set.
2. **Validation phase**: when the client requests commit, the server checks for conflicts with other transactions that overlapped in time. If validation fails, the transaction is aborted (or conflict resolution is used).
3. **Update phase**: if validation succeeds, tentative versions are made permanent (written to permanent storage) and the transaction commits.

**Validation (backward validation)**: transaction Tv is checked against earlier overlapping transactions Ti that committed before Tv started validation. Rules:
- If Ti writes an object that Tv reads (Ti's write set ∩ Tv's read set ≠ ∅), validation fails, because Tv read stale data.
- Otherwise Tv passes validation. (Writes are applied in commit order, so write-write conflicts cannot occur.)

**Forward validation** checks Tv's write set against the read sets of still-active transactions; it allows a choice of aborting Tv or the others.

In a distributed system, each server validates its own part of the transaction during the first phase of two-phase commit, and all servers must validate in the same global order to avoid commitment deadlock and inconsistent serial orders.

**Advantages**
- No locking, so no deadlock and no lock overhead.
- High concurrency when conflicts are rare; with forward validation, read-only transactions always pass validation.
- Abort is cheap because nothing was written permanently.

**Disadvantages**
- Under heavy conflicts many transactions abort and restart; starvation is possible.
- Wasted work for aborted transactions.

#### 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 |

## Check yourself

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

1. Under timestamp ordering, when is transaction T (timestamp Tc) refused a write on an object?
   A. When Tc is larger than every read timestamp
   B. When a later transaction has already read the object (Tc less than max read timestamp)
   C. When the object is unlocked
   D. Never, writes are always allowed
   Answer: B. A write by an earlier transaction would invalidate a later transaction's read, so T is aborted. (Key point: Timestamp write rule)

2. In backward validation, Tv fails validation when:
   A. Tv writes an object that an earlier committed transaction also wrote
   B. An overlapping earlier committed transaction wrote an object that Tv read
   C. Tv has an empty write set
   D. Tv started before any other transaction
   Answer: B. If Ti's write set intersects Tv's read set, Tv read stale data. (Key point: Backward validation)

3. Which pair of methods is free of deadlock?
   A. Locking and timestamp ordering
   B. Locking and optimistic
   C. Timestamp ordering and optimistic
   D. All three
   Answer: C. Neither uses waiting on locks held by each other; only locking can deadlock. (Key point: Deadlock comparison)

4. Optimistic control suits which situation best?
   A. Many conflicts, mostly writes
   B. Few conflicts, mostly reads
   C. Long transactions holding many locks
   D. Systems needing a lock table
   Answer: B. With rare conflicts few aborts occur, and read-only transactions always commit. (Key point: When optimistic is best)

## Close variants set in other exams

- [Distributed concurrency control methods](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Adistributed-cc-methods) — 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

## Related in other subjects

- [Comparison of G-S and N-R load flow](https://www.bctengineer.com/question.md?key=semester_5%2Fpower_system_analysis_ii%3Ags-vs-nr-comparison) — Power System Analysis II, chapter 2, asked 3×
- [Series versus parallel circuit comparison](https://www.bctengineer.com/question.md?key=semester_1%2Fbasic_electrical_engineering%3Aseries-parallel-comparison-table) — Basic Electrical Engineering, chapter 1
- [AC vs DC transmission comparison](https://www.bctengineer.com/question.md?key=semester_8%2Ftransmission_and_distribution_system_design%3Aac-vs-dc-transmission) — Transmission and Distribution System Design, chapter 1
- [Comparison of DC shunt and series generators](https://www.bctengineer.com/question.md?key=semester_4%2Felectrical_machines_i%3Ashunt-vs-series-generator-comparison) — Electrical Machines I, chapter 3