---
title: "Cascading aborts; three-phase commit"
subject: "Distributed System"
chapter: 8
key: "semester_7/distributed_system:cascading-aborts-3pc"
source: https://www.bctengineer.com/q/semester_7/distributed_system/cascading-aborts-3pc
site: BCT Engineering
---

# Cascading aborts; three-phase commit

Distributed System · Chapter 8: Transaction and Concurrency Control

- Asked in: 2074 Asoj, 8 marks
- 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-3pc
- Whole chapter: https://www.bctengineer.com/md/semester_7/distributed_system/chapter-8

## Question

How does cascading aborts occur and are solved? Explain three phase commit protocol with state diagram.

## Short answer

Cascading aborts occur when a transaction uses uncommitted data that later aborts, chaining aborts to readers; solved by strict two-phase locking or reading committed data only. Three-phase commit adds a pre-commit phase after voting to prevent blocking: canCommit, preCommit, doCommit, letting participants decide commit/abort if coordinator crashes.

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

#### Three-phase commit
The **three-phase commit protocol (3PC)** is an extension of 2PC that avoids blocking when the coordinator crashes, by adding a **pre-commit** state between the vote and the commit. Its states satisfy two conditions: there is no state from which a process can move directly to both COMMIT and ABORT, and there is no state in which a process cannot yet make a final decision but can move directly to COMMIT.

**Phases**
1. **canCommit**: the coordinator sends *Prepare/canCommit?*; participants reply Yes or No. If any No, or a timeout, the coordinator sends abort.
2. **preCommit**: if all say Yes, the coordinator sends *Pre-commit*; participants acknowledge. Now everyone knows that all have voted Yes.
3. **doCommit**: after all acknowledgements, the coordinator sends *Commit*; participants commit and reply.

```text
Coordinator states:
 INIT --canCommit?--> WAIT --all Yes--> PRECOMMIT --acks--> COMMIT
                        |any No/timeout
                        v
                      ABORT

Participant states:
 INIT --Yes--> READY --preCommit--> PRECOMMIT --commit--> COMMIT
   |No          |abort/timeout
   v            v
 ABORT        ABORT
```

**Recovery rule**: if the coordinator fails, the participants elect a new one. If any participant is in PRECOMMIT, all can commit; if none is, all can abort. Timeouts drive transitions so the system never blocks indefinitely.

**Compared with 2PC**: 3PC is non-blocking under crash failures (not for network partitions), but needs one more round of messages, so it costs more and is less used in practice.

## Check yourself

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

1. How does a cascading abort arise?
   A. A transaction reads uncommitted data from a writer that later aborts
   B. Two transactions commit at once
   C. A coordinator crashes
   D. A lock times out
   Answer: A. The dirty read becomes invalid when the writer aborts, so the reader (and its readers) must abort. (Key point: Cause of cascading abort)

2. Which approach avoids cascading aborts?
   A. Strict execution / strict 2PL, delaying access until the last writer commits or aborts
   B. Releasing write locks early
   C. Timestamps with no waiting
   D. One-phase commit
   Answer: A. Delaying reads and writes of an object until the previous writer finishes prevents dirty reads. (Key point: Solution)

3. Why does 3PC add a pre-commit state?
   A. To let all participants know everyone voted Yes, so they can decide without the coordinator
   B. To reduce messages
   C. To skip voting
   D. To allow participants to abort unilaterally after voting Yes
   Answer: A. After pre-commit everyone knows all votes were Yes, removing the uncertain state that blocks 2PC. (Key point: Pre-commit state)

4. Under which failures is 3PC non-blocking?
   A. Crash failures, but not network partitions
   B. Network partitions only
   C. All failures
   D. None
   Answer: A. 3PC handles crashes but not partitions, and costs an extra message round. (Key point: 3PC limits)

## Related in Distributed System

- [Cascading aborts; atomic commit protocol](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Acascading-aborts-acp) — Distributed System, chapter 8
- [Short note: Three-phase commit](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Athree-phase-commit-note) — Distributed System, chapter 8