Roles

  • Coordinator: the node in charge of deciding whether the transaction may commit (50:16, 50:41).
  • Participants: the other nodes involved in this transaction — not necessarily every node in the cluster (50:41, 51:57).

The commit path

sequenceDiagram
    participant App
    participant C as Coordinator (Node 1)
    participant P2 as Participant 2
    participant P3 as Participant 3
    App->>C: COMMIT
    Note over C,P3: Phase 1 — Prepare
    C->>P2: prepare
    C->>P3: prepare
    P2-->>C: OK
    P3-->>C: OK
    Note over C,P3: Phase 2 — Commit
    C->>P2: commit
    C->>P3: commit
    P2-->>C: OK
    P3-->>C: OK
    C-->>App: success
  1. Prepare phase: the coordinator asks every participant whether the transaction may commit. Each participant decides using only its own local context (50:57, 51:13, 53:57).
  2. Commit phase: once all participants say OK, the coordinator tells everyone to commit; each applies changes and (under synchronous commit) flushes before acknowledging (51:57, 52:35).
  3. Only then does the client get "committed" (52:35, 52:52).

All inbound and outbound protocol messages are themselves written to the WAL and flushed, so a crashed node can recover its position in the protocol. They can go in the same WAL as ordinary queries (51:35, 51:57, 54:59).

How a participant decides (student question)

It is the same single-node machinery already covered (53:11):

  • OCC: the validation phase may find the write set intersects a running transaction → cannot commit.
  • 2PL: if locks are held and updates are complete, it is fine.
  • Integrity constraints: e.g. deferred index checks that only detect a duplicate key at commit time (53:43).

The abort path

  • The moment one participant votes abort, the transaction is dead regardless of what the others think (54:12).
  • Asymmetry: on abort the coordinator does not wait for phase-2 acknowledgements before telling the client — the outcome is already certain (54:39).

Recovery

SituationBehavior
Participant crashed after voting OK on prepareOn restart, reads its log, contacts the coordinator to learn the transaction's real fate, then either rolls back (changes are in its WAL) or applies (54:59)
Participant crashed before the prepared phaseJust aborts — a crash mid-updates is equivalent to aborting (56:02)
Coordinator crashed after everyone agreedOn restart it tells all nodes to commit, even if the client was never told (56:02, 56:26)
Participant fails to answer prepareThe coordinator assumes an abort and aborts the transaction everywhere (58:09)
  • Durability rule: if the changes reached disk but the acknowledgement never reached the client before the crash, the transaction still counts as committed — it is up to the application server to go back and check (56:26, 56:57).
  • Coordinator failure is the blocking problem: participants detect it via heartbeat timeouts, then negotiate among themselves. While they do, the system is unavailable — no other transaction may commit, because a second transaction that read from the undecided first one could commit and violate ACID if the first aborts (56:57, 57:35, 57:47, 58:09).

Two optimizations

1. Early prepare voting (rare)

  • If you know a given query is the last one this transaction will send to that node, piggyback the prepare vote on the query response: you get back the result and an OK/abort vote, eliminating a later round trip (58:31, 59:12).
  • Rarely implemented: SQL gives you no way to know where a query will run or that it is the last one. JDBC may expose such a flag, and VoltDB supports it, but most systems cannot (59:21, 59:46).

2. Early acknowledgement after prepare (very common)

  • Once the prepare phase gets all OKs, the transaction is committing no matter what, so the coordinator can return success to the client immediately and run phase 2 afterwards (59:46, 1:00:01).
  • Saves exactly one round trip of waiting — the commit phase still runs, you just do not block on it. Safe because the recovery protocol already handles crashes during commit (1:00:23, 1:01:04).

Why phase 2 acknowledgements are still required (student question)

  • The coordinator must know everyone applied the change before it commits the next transaction, so that the next transaction reading data written by the first sees the correct version (1:03:03, 1:04:56).
  • A second commit request can start but cannot commit until the first finishes phase 2 (1:03:27).
  • Subtlety: after receiving the commit message the participants can begin committing another transaction, but the coordinator cannot, because it does not yet know its message arrived (1:04:06, 1:04:36).

Repeated warning throughout: "this is hard, there are a lot of corner cases you have to deal with" (1:02:40).