---
title: "Distributed Transactions and the Blocking Case of Two-Phase Commit"
description: "A transaction spanning several stores needs one atomic decision. Two-phase commit gets it by making participants promise before the coordinator decides, and its known weakness is that a coordinator fa"
canonical: https://lightmysky.com/learn/computing/distributed-transactions-and-the-blocking-case-of-two-phase-commit-mt_MP_B_a_EwW
source: https://lightmysky.com/learn/computing/distributed-transactions-and-the-blocking-case-of-two-phase-commit-mt_MP_B_a_EwW.md
retrieved: 2026-09-12
---

> **Agent view.** This is the Markdown twin of the page, for tools and assistants.
> When to use this site, and the call that answers each job: https://lightmysky.com/agent-instructions.md
> API description (OpenAPI 3.1): https://lightmysky.com/openapi.json · Authentication: https://lightmysky.com/auth.md
> Pricing: https://lightmysky.com/pricing.md · Catalog: https://lightmysky.com/llms.txt · Full catalog: https://lightmysky.com/llms-full.txt
> Every machine-readable file on this domain: https://lightmysky.com/.well-known/ai-catalog.json
> Ask for Markdown with `Accept: text/markdown`, a `.md` address, or `?mode=agent`.

# Distributed Transactions and the Blocking Case of Two-Phase Commit

A transaction spanning several stores needs one atomic decision. Two-phase commit gets it by making participants promise before the coordinator decides, and its known weakness is that a coordinator failure at the wrong moment leaves participants holding locks with nobody to ask.

Subject: Computing · Area: Data & Databases · Ages 22 to 24
Page: https://lightmysky.com/learn/computing/distributed-transactions-and-the-blocking-case-of-two-phase-commit-mt_MP_B_a_EwW

## Ready when they can

- Walk both phases and say what a participant has promised once it votes yes
- Identify the window where a coordinator failure blocks the participants
- Say how running consensus on the commit decision removes the blocking case, and what it costs

## Lesson: Two phases, one atomic decision

Like the single-object view for one store, a transaction that touches several stores needs a single outcome: commit everywhere or abort everywhere. Phase one: the coordinator asks every participant to prepare, and each votes yes or no. A yes vote is a promise: I will obey your decision, and I hold my locks until you tell me.

**Example.** One order lives in two stores. The coordinator asks both. Both vote yes, so the coordinator sends commit and both commit. Had one voted no, the coordinator would send abort and both would drop the change. The decision is one; the stores just obey it.

The blocking window opens once a participant votes yes: it can no longer decide alone, because another store may already hold a commit order from the coordinator. If the coordinator crashes in that window, yes-voters wait with locks held and nobody can answer them. A crash before anyone voted yes is harmless, since everyone simply aborts.

Consensus on the decision removes the single decider: the replicas agree among themselves on commit or abort, so survivors always finish even when some fail. The price is extra rounds of messages on every commit, not just when something breaks.

**Recap.** Yes means obey and wait; a dead coordinator in that window leaves voters blocked.

## Practice

8 questions on this page, each with its working shown.

## Needs first

- [Transactions and the ACID Promise](https://lightmysky.com/learn/computing/transactions-and-the-acid-promise-mt_8Egjmafq-L)
- [Crash Recovery and Write-Ahead Logging](https://lightmysky.com/learn/computing/crash-recovery-and-write-ahead-logging-mt_JFPafSWOWF)
- [Linearizability and Checking a History](https://lightmysky.com/learn/computing/linearizability-and-checking-a-history-mt_lTaHmlGtuo)

## Opens up

- [Conflict-Free Replicated Data Types](https://lightmysky.com/learn/computing/conflict-free-replicated-data-types-mt_Bhf1nu-9jz)