---
title: "Nested vs distributed transaction; 2PC"
subject: "Distributed System"
chapter: 8
key: "semester_7/distributed_system:nested-vs-distributed-2pc"
source: https://www.bctengineer.com/q/semester_7/distributed_system/nested-vs-distributed-2pc
site: BCT Engineering
---

# Nested vs distributed transaction; 2PC

Distributed System · Chapter 8: Transaction and Concurrency Control

- Asked in: 2075 Chaitra, 2+6 marks; 2070 Chaitra, 2+6 marks (asked 2 times)
- Video: [Two phase Commit Protocol | Transaction | Distributed Systems | Lec-61 | Bhanu Priya](https://www.youtube.com/watch?v=W-TadPbi--A) — Education 4u
- Answer checked by Claude Opus 5.5 (high effort) on 2026-10-14
- Page: https://www.bctengineer.com/q/semester_7/distributed_system/nested-vs-distributed-2pc
- Whole chapter: https://www.bctengineer.com/md/semester_7/distributed_system/chapter-8

## Question

Compare nested transactions and distributed transactions with examples. Explain the two-phase commit protocol / how commitment is ensured in handling distributed transactions.

## Short answer

Nested transactions have a tree of sub-transactions that can run concurrently, where a child abort does not abort the parent. Distributed transactions involve multiple servers and use two-phase commit (2PC) for atomicity. 2PC: coordinator asks canCommit?, if all vote Yes it sends doCommit, else doAbort; participants then commit or abort accordingly.

## Answer

#### Nested transactions versus distributed transactions
- **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.

- **Distributed transaction**: a (flat or nested) transaction whose operations access objects on **several servers**. What matters is not the structure of the transaction but that its data are distributed. It needs a coordinator to commit or abort it at all servers. Example: transferring money from an account at bank server X to an account at server Y.

| Point | Nested transaction | Distributed transaction |
|---|---|---|
| Basis | Structure of the transaction (tree of sub-transactions) | Location of the objects (many servers) |
| Parts | Sub-transactions | Operations at different servers |
| Concurrency | Sub-transactions run in parallel | Servers run parts concurrently |
| Partial failure | A child can abort without the parent aborting | Whole transaction aborts if one server aborts |
| Commit | Provisional commit of children, final at top | Atomic commit protocol (2PC) |
| Can be single server? | Yes | No |

A transaction can be both (a **nested distributed** transaction, e.g. a *book trip* that has sub-transactions at airline, hotel and taxi servers).

#### Commitment: two-phase commit
The **two-phase commit protocol (2PC)** makes sure that all servers (participants) of a distributed transaction either all commit or all abort. One server acts as the **coordinator** (usually the one that the client contacted); others are **participants**.

**Phase 1: voting**
1. The coordinator sends **canCommit?** to every participant.
2. Each participant replies **Yes** (it has saved the transaction's changes to permanent storage and is prepared; it can no longer unilaterally abort) or **No** (it aborts at once).

**Phase 2: completion**
3. If all votes (including the coordinator's own) are Yes, the coordinator records the decision and sends **doCommit**; if any vote is No or a timeout occurs, it sends **doAbort**.
4. Participants carry out the decision and send **haveCommitted** to the coordinator.

```text
Coordinator            Participants
   |--- canCommit? ------->|
   |<------ Yes / No ------|
   | (decide, log)         |
   |--- doCommit/doAbort ->|
   |<---- haveCommitted ---|
```

**Failures**
- If a participant crashes before voting, the coordinator times out and aborts.
- A participant that has voted Yes is in the **uncertain** state; if the coordinator fails it must wait (it blocks) or ask other participants for the decision.
- On recovery, servers use their logs to complete the protocol.

**Drawbacks**: blocking if the coordinator fails, and extra messages and delays (about 3N messages for N participants).

## Check yourself

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

1. What is the basis for calling a transaction nested versus distributed?
   A. Nested is about the tree structure of sub-transactions; distributed is about objects being on several servers
   B. Nested is about several servers; distributed is about a tree of sub-transactions
   C. Both mean the same thing
   D. Nested transactions cannot be concurrent
   Answer: A. Nesting concerns transaction structure, whereas distribution concerns where the accessed objects are located. (Key point: Nested vs distributed basis)

2. In a nested transaction, what happens if one sub-transaction aborts?
   A. The parent must abort too
   B. The parent can retry or choose another action
   C. All servers crash
   D. The transaction commits anyway with corrupt data
   Answer: B. A child can abort without aborting its parent, e.g. try another taxi company. (Key point: Partial failure)

3. In the two-phase commit protocol, what happens in phase 1?
   A. The coordinator sends doCommit
   B. The coordinator sends canCommit? and participants vote Yes or No
   C. Participants send haveCommitted
   D. The client commits locally
   Answer: B. Phase 1 is voting; phase 2 is the completion with doCommit or doAbort. (Key point: 2PC phases)

4. When does the coordinator send doCommit?
   A. When at least one participant votes Yes
   B. When a majority vote Yes
   C. When all votes, including its own, are Yes
   D. Always, after a timeout
   Answer: C. Any No vote or timeout leads to doAbort; commit requires unanimous Yes. (Key point: Commit decision)

5. What does a participant that voted Yes do if the coordinator fails before sending the decision?
   A. It aborts unilaterally
   B. It commits unilaterally
   C. It is uncertain and must wait (block) or ask other participants
   D. It elects itself coordinator and ignores logs
   Answer: C. Having voted Yes it can no longer abort on its own, so it is blocked in the uncertain state; this is 2PC's drawback. (Key point: Uncertain state)

## Related in Distributed System

- [Distributed deadlock; two-phase commit](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Adistributed-deadlock-2pc) — 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
- [Distributed and nested distributed transactions](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Adistributed-transaction-nested) — Distributed System, chapter 8
- [Short note: Two-phase commit](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Atwo-phase-commit-note) — Distributed System, chapter 8, asked 2×
- [Transaction, nested transaction, atomicity](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Atransaction-nested-atomicity) — Distributed System, chapter 8
- [Flat/nested transactions; optimistic CC](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Aflat-nested-optimistic) — Distributed System, chapter 8