--- title: "Two-version locking; optimistic CC" subject: "Distributed System" chapter: 8 key: "semester_7/distributed_system:two-version-optimistic" source: https://www.bctengineer.com/q/semester_7/distributed_system/two-version-optimistic site: BCT Engineering --- # Two-version locking; optimistic CC Distributed System · Chapter 8: Transaction and Concurrency Control - Asked in: 2075 Asoj, 2+6 marks - Video: [169. optimistic concurrency control technique](https://www.youtube.com/watch?v=kPJT05J6_6o) — GATE CSE LECTURES BY AMIT KHURANA - Answer checked by Claude Opus 5.5 (high effort) on 2026-10-14 - Page: https://www.bctengineer.com/q/semester_7/distributed_system/two-version-optimistic - Whole chapter: https://www.bctengineer.com/md/semester_7/distributed_system/chapter-8 ## Question Write down the rule of two-version locking. Explain how Optimistic concurrency control mechanism works? ## Short answer Two-version locking maintains a committed and a tentative version. Read locks are compatible with write locks but not commit locks; write locks are exclusive for tentative versions; commit locks wait for readers. Optimistic concurrency control uses private copies in a working phase, validates by checking for conflicts at commit, and updates permanently if no conflict is detected. ## Answer #### Two-version locking **Two-version locking** is a concurrency control method that allows one transaction to write tentative versions of an object while others read the last committed version. Each object can have two versions: a **committed** version and a **tentative** version (written by an uncommitted transaction). Locks have three modes: **read**, **write** and **commit**. - A **read lock** is allowed even if another transaction holds a write lock (it reads the committed version), but not if a commit lock is held. - A **write lock** is allowed only if no other write lock is held (only one tentative version can exist); it can coexist with read locks. - Before commit, a transaction converts its write locks to **commit locks**. This must wait until all read locks on the object are released (readers of the old version finish), and then the tentative version becomes the committed version. | Held \ Requested | Read | Write | Commit | |---|---|---|---| | None | OK | OK | OK | | Read | OK | OK | Wait | | Write | OK | Wait | - | | Commit | Wait | Wait | - | This gives more concurrency than simple locking (readers are not blocked by writers) but commit can be delayed, and deadlock is still possible. #### Optimistic concurrency control **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. ## Check yourself The answer's key points as multiple-choice questions, with the correct option and why. 1. In two-version locking, what can a reader do while another transaction holds a write lock on the object? A. Wait until the writer commits B. Read the last committed version C. Read the writer's tentative version D. Abort the writer Answer: B. The writer works on a tentative version, so readers are allowed to read the committed version and are not blocked. (Key point: Two-version locking read/write) 2. Before committing, a transaction converts its write locks to commit locks. When can this conversion complete? A. Immediately, since the tentative version is private B. Only after all other write locks are released C. After all read locks on the object are released D. Only after the validation phase Answer: C. Readers of the old committed version must finish first, because the tentative version replaces it at commit. (Key point: Commit lock conversion) 3. What is the correct order of phases in optimistic concurrency control? A. Validation, working, update B. Working, validation, update C. Working, update, validation D. Update, working, validation Answer: B. Transactions work on private copies, are validated at commit request, and only then are tentative versions made permanent. (Key point: Optimistic phases) 4. In backward validation, when does Tv fail validation against an earlier overlapping committed transaction Ti? A. When Ti's write set intersects Tv's read set B. When Ti's read set intersects Tv's read set C. When Ti and Tv have the same timestamp D. When Tv's write set is empty Answer: A. If Ti wrote an object that Tv read, Tv read stale data, so Tv must be aborted. (Key point: Backward validation rule) ## Related in Distributed System - [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 - [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 - [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 ## Related in other subjects - [Short note: version control](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Aversion-control) — Software Engineering, chapter 10 - [Two peg test: collimation inclined up or down](https://www.bctengineer.com/question.md?key=semester_3%2Fsurveying_i%3Atwo-peg-dumpy-cd-df-120m) — Surveying I, chapter 5 - [Define RT works, objectives, purposes of spur](https://www.bctengineer.com/question.md?key=semester_6%2Firrigation_and_drainage_engineering%3Ariver-training-objectives-spur-purposes) — Irrigation and Drainage Engineering, chapter 6 - [Elimination reaction; dehydrohalogenation; Saytzeff's rule](https://www.bctengineer.com/question.md?key=semester_2%2Fengineering_chemistry%3Aelimination-saytzeff) — Engineering Chemistry, chapter 10, asked 2×