--- title: "Concurrency control goals and mechanisms" subject: "Distributed System" chapter: 8 key: "semester_7/distributed_system:cc-goals-mechanisms" source: https://www.bctengineer.com/q/semester_7/distributed_system/cc-goals-mechanisms site: BCT Engineering --- # Concurrency control goals and mechanisms Distributed System · Chapter 8: Transaction and Concurrency Control - Asked in: Model question - Answer checked by Claude Opus 5.5 (high effort) on 2026-10-14 - Page: https://www.bctengineer.com/q/semester_7/distributed_system/cc-goals-mechanisms - Whole chapter: https://www.bctengineer.com/md/semester_7/distributed_system/chapter-8 ## Question Define concurrency control and its need in any transaction. What are the major goals and mechanisms of concurrency control? ## Short answer Concurrency control coordinates interleaved transactions to produce serially equivalent results, preventing lost updates and dirty reads. Goals include serializability, consistency, and maximum concurrency. Major mechanisms are locking (strict two-phase locking with shared/exclusive locks), timestamp ordering, and optimistic validation at commit. ## Answer #### Concurrency control and its need **Concurrency control** is the activity of coordinating concurrent transactions that access shared data so that their combined effect is correct, as if they ran one at a time (**serial equivalence**), while allowing as much parallelism as possible. **Need**: without it, interleaved transactions cause - **Lost update**: one transaction overwrites another's update. - **Inconsistent retrieval**: a transaction reads some values before and others after another transaction's update. - **Dirty read and cascading abort**: reading uncommitted data of a transaction that later aborts. - **Premature writes**: wrong restoring of old values after aborts. #### Goals - Isolation of transactions (serializability). - Preserve consistency of the data (ACID). - Maximize concurrency and throughput, and reduce response time. - Prevent or resolve deadlock and starvation. - Make aborts safe: avoid cascading aborts (recoverability). #### Mechanisms 1. **Locking** (pessimistic): a transaction locks data before access and holds it (strict 2PL) until commit. Conflicts cause waiting; deadlock is possible. 2. **Timestamp ordering**: each transaction gets a timestamp; conflicting operations must be executed in timestamp order; late operations abort the transaction. No deadlock. 3. **Optimistic concurrency control**: work on private copies, validate at commit time, and abort if there was a conflict. 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. **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. **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. ## Check yourself The answer's key points as multiple-choice questions, with the correct option and why. 1. What does concurrency control aim to guarantee about interleaved transactions? A. Every transaction runs strictly one after another with no overlap B. The combined effect is the same as some serial execution, while allowing parallelism C. Transactions never abort D. Each transaction gets its own copy of the whole database Answer: B. Serial equivalence means the interleaved result equals a serial order, yet parallelism is kept as high as possible. (Key point: Serial equivalence) 2. A transaction reads account A before another transaction's transfer and account B after it, so the total is wrong. This problem is called: A. Lost update B. Dirty read C. Inconsistent retrieval D. Premature write Answer: C. Reading some values before and others after another transaction's update gives inconsistent retrieval. (Key point: Inconsistent retrieval) 3. What does strict two-phase locking add to ordinary 2PL? A. Locks are released as soon as the data is used B. Locks are held until commit or abort, preventing dirty reads and cascading aborts C. Only read locks are allowed D. Transactions get timestamps Answer: B. Holding all locks to the end means no one can read uncommitted data, so cascading aborts are avoided. (Key point: Strict 2PL) 4. What is the correct order of phases in optimistic concurrency control? A. Validation, working, update B. Working, update, validation C. Working, validation, update D. Locking, working, commit Answer: C. Transactions work on private copies, are validated at commit request, and only then made permanent in the update phase. (Key point: Optimistic phases) ## Related in Distributed System - [Goals, need of transparency, challenges](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Agoals-transparency-challenges) — Distributed System, chapter 1 - [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 methods compared](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Acc-methods-compare) — 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 - [Need of transaction; phantom deadlock](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Atransaction-deadlock-phantom) — Distributed System, chapter 8 - [Goals and design challenges of DS](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Ads-goals-challenges) — Distributed System, chapter 1, asked 3× ## Related in other subjects - [Flow control mechanisms in data communication](https://www.bctengineer.com/question.md?key=semester_8%2Ftelecommunications%3Aflow-control-mechanisms) — Telecommunications, chapter 8 - [Horizontal control specification for major traverse](https://www.bctengineer.com/question.md?key=semester_4%2Fsurveying_ii%3Atraverse-horizontal-control-specification) — Surveying II, chapter 1 - [Need for FACTS and major FACTS devices](https://www.bctengineer.com/question.md?key=semester_8%2Fhigh_voltage_engineering%3Afacts-devices-need-types) — High Voltage Engineering, chapter 1 - [Need of control statements](https://www.bctengineer.com/question.md?key=semester_1%2Fcomputer_programming%3Awhy-control-statements) — Computer Programming, chapter 5, asked 2×