--- title: "Flat/nested transactions; optimistic CC" subject: "Distributed System" chapter: 8 key: "semester_7/distributed_system:flat-nested-optimistic" source: https://www.bctengineer.com/q/semester_7/distributed_system/flat-nested-optimistic site: BCT Engineering --- # Flat/nested transactions; optimistic CC Distributed System · Chapter 8: Transaction and Concurrency Control - Asked in: 2072 Kartik, 4+6 marks - Video: [Part-102: Difference between Flat Transaction and Nested Transaction with structure in brief and eas](https://www.youtube.com/watch?v=tqXcwxpcwzc) — Knowledge Hub - Answer checked by Claude Opus 5.5 (high effort) on 2026-10-14 - Page: https://www.bctengineer.com/q/semester_7/distributed_system/flat-nested-optimistic - Whole chapter: https://www.bctengineer.com/md/semester_7/distributed_system/chapter-8 ## Question Define flat and nested transaction. Discuss the approach of optimistic concurrency control in distributed transactions. ## Short answer A flat transaction is a single-level all-or-nothing operation. A nested transaction comprises sub-transactions; children can run concurrently and abort without aborting the parent. Optimistic concurrency control works in three phases: working on private copies, validation by checking for read-write conflicts with earlier committed overlapping transactions, and update if validation passes. ## Answer #### Flat and nested transactions - **Flat transaction**: a single-level transaction that issues its requests one after another on one or more objects. If any step fails, the whole transaction aborts and everything is undone. Example: a bank transfer *withdraw(A, 100); deposit(B, 100)*. Its drawback is that it cannot commit part of its work and has no internal concurrency. - **Nested transaction**: a transaction made of sub-transactions in a tree. The top-level transaction contains child transactions, which may contain their own children. Sub-transactions at the same level can run **concurrently**, and a sub-transaction can abort without aborting its parent; the parent may retry or choose another action. Example: a *book trip* transaction with sub-transactions *book flight*, *book hotel*, *book taxi*. If the taxi booking fails, the parent can try another company. Rules of nested transactions: - A sub-transaction commits only provisionally; its result becomes permanent only when all its ancestors commit up to the top level. - If a parent aborts, all its sub-transactions abort, even those that provisionally committed. - A child sees the parent's changes, but the parent does not see the child's until the child commits. #### Optimistic concurrency control in distributed transactions **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. **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. **In distributed transactions**: each server validates its own part of the transaction during the first (voting) phase of two-phase commit. If any server finds a conflict, it votes No, and the transaction is aborted everywhere. If each server validates one transaction at a time, **commitment deadlock** can arise (server X is validating T and waits for U, while server Y is validating U and waits for T); parallel validation avoids this. The servers must also agree on one serial order, for example by a global validation step after the local ones, or by giving each transaction a globally unique number at the start of validation. ## Check yourself The answer's key points as multiple-choice questions, with the correct option and why. 1. What happens to a provisionally committed sub-transaction if its parent aborts? A. It stays committed B. It is also aborted C. It becomes a top-level transaction D. It is retried automatically Answer: B. Its results become permanent only when all ancestors commit up to the top level. (Key point: Nested transaction rules) 2. What does optimistic concurrency control assume and do? A. Conflicts are frequent, so locks are taken first B. Conflicts are rare, so transactions proceed without locks and are checked at commit C. Transactions must run serially D. Only timestamps are compared on every read Answer: B. Work proceeds on private copies and conflicts are checked only at validation time. (Key point: Optimistic approach assumption) 3. In backward validation, when does Tv fail? A. When an earlier overlapping committed transaction wrote an object that Tv read B. When Tv wrote an object nobody read C. When Tv is the first transaction D. When locks are held Answer: A. The write set of Ti intersecting Tv's read set means Tv read stale data. (Key point: Validation failure) 4. How is optimistic control applied in a distributed transaction? A. Each server validates its part as part of 2PC; any No vote aborts the transaction everywhere B. Only the client validates C. Validation is skipped D. Only the first server validates Answer: A. Servers validate independently and vote; to avoid commitment deadlock they should validate in a consistent global order. (Key point: Optimistic in distributed transactions) ## 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 - [Nested transactions; optimistic CC advantages](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Anested-optimistic-advantages) — Distributed System, chapter 8 - [Nested vs distributed transaction; 2PC](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Anested-vs-distributed-2pc) — Distributed System, chapter 8, asked 2× - [Distributed and nested distributed transactions](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Adistributed-transaction-nested) — 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 - [Transaction, nested transaction, atomicity](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Atransaction-nested-atomicity) — Distributed System, chapter 8