--- title: "Cascading aborts; atomic commit protocol" subject: "Distributed System" chapter: 8 key: "semester_7/distributed_system:cascading-aborts-acp" source: https://www.bctengineer.com/q/semester_7/distributed_system/cascading-aborts-acp site: BCT Engineering --- # Cascading aborts; atomic commit protocol Distributed System · Chapter 8: Transaction and Concurrency Control - Asked in: 2072 Kartik, 8 marks - Video: [Two-Phase Commit (2PC) Protocol Explained for Beginners | Distributed Transactions](https://www.youtube.com/watch?v=Ppe3DmNAWrk) — CodeLucky - Answer checked by Claude Opus 5.5 (high effort) on 2026-10-14 - Page: https://www.bctengineer.com/q/semester_7/distributed_system/cascading-aborts-acp - Whole chapter: https://www.bctengineer.com/md/semester_7/distributed_system/chapter-8 ## Question How does cascading aborts occur and can be solved? Explain the needs and roles of atomic commit protocol in distributed system. ## Short answer Cascading aborts happen when a transaction reads uncommitted data and the writer later aborts, causing a chain of aborts. Strict 2PL or strict timestamp ordering (only committed reads) prevents it. Atomic commit protocols coordinate distributed transactions: a coordinator collects votes;if all vote yes, commit, else abort, ensuring atomicity and durability across servers, with recovery support. ## Answer #### Cascading aborts A **cascading abort** happens when a transaction reads a value written by another transaction that has not yet committed (a *dirty read*), and the writer then aborts. The reader has used data that never officially existed, so it must also abort, and every transaction that read the reader's data must abort too, forming a chain. Example: T writes A = 50 (old value 30); U reads A = 50 and writes B based on it; T aborts, so A returns to 30. U's work is invalid and U must abort; any V that read B aborts too. **Solutions** - **Strict execution**: delay reads and writes of an object until the transaction that last wrote it has committed or aborted. In practice this is **strict two-phase locking** (hold write locks until commit/abort). - Allow transactions to read only committed data (no dirty reads). - In timestamp ordering, make a reader wait for the tentative version to commit (strict timestamp ordering). This also avoids the related problem of **premature writes** (restoring before-images wrongly) when aborts occur. #### Need and roles of atomic commit protocol An **atomic commit protocol (ACP)** is used to make sure that a distributed transaction, which has operations at several servers, is committed or aborted at all of them together. **Need**: in a one-server transaction, commit is a local action. In a distributed transaction, if one server commits while another aborts (due to crash, lock conflict or validation failure), atomicity is violated and the data become inconsistent. A one-phase commit (the coordinator just tells everybody to commit) cannot handle a server that has to abort unilaterally. **Roles** - Ensure atomicity: all participants reach the same decision (commit if all vote Yes, otherwise abort). - A **coordinator** collects votes and announces the decision; **participants** vote and carry it out. - Ensure durability: participants save tentative changes to permanent storage before voting Yes, so the decision can be completed after a crash. - Allow any participant to veto (abort) the transaction. - Provide recovery from crashes and lost messages using logs and timeouts. The best-known ACPs are **two-phase commit (2PC)** and **three-phase commit (3PC)**. ## Check yourself The answer's key points as multiple-choice questions, with the correct option and why. 1. T writes A=50 (old 30), U reads 50 and writes B, then T aborts. What must happen? A. U must abort, as must anyone who read B B. Only T aborts C. U commits with A=50 D. A stays at 50 Answer: A. U used data that never officially existed, so it and its dependants abort in a chain. (Key point: Cascading abort example) 2. How is cascading abort avoided in timestamp ordering? A. Readers wait for the tentative version to commit or abort B. Readers ignore tentative versions and use any value C. Writers are never aborted D. Timestamps are not used Answer: A. Strict timestamp ordering makes readers wait for the tentative version's fate. (Key point: Strict timestamp ordering) 3. Why is one-phase commit not enough for distributed transactions? A. It uses too many messages B. A server that must abort unilaterally (crash, lock conflict, validation) cannot tell the coordinator C. It requires logs D. It needs a timestamp Answer: B. Without a voting phase, one server might commit while another aborts, violating atomicity. (Key point: Need for ACP) 4. Why do participants save tentative changes to permanent storage before voting Yes? A. So the decision can be completed after a crash B. To avoid voting C. To release locks D. To skip the coordinator Answer: A. Having saved their changes, they can still commit after a crash if the decision is commit. (Key point: Durability role) ## Related in Distributed System - [Cascading aborts; three-phase commit](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Acascading-aborts-3pc) — Distributed System, chapter 8 - [Distributed deadlock; two-phase commit](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Adistributed-deadlock-2pc) — Distributed System, chapter 8 - [Threads, checkpoint, distributed commit](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Athreads-checkpoint-commit) — Distributed System, chapter 3 - [Short note: Distributed commit](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Adistributed-commit-note) — Distributed System, chapter 8 - [Atomic commitment protocols (2PC, 3PC)](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Aacp-two-three-phase) — Distributed System, chapter 8