Three-Phase Commit (3PC)

Comment éviter le blocage de 2PC quand le coordinateur tombe — en sacrifiant la tolérance aux partitions réseau et en ajoutant un round-trip.

Problème

Le défaut majeur de 2PC est l'état « prepared » : si le coordinateur tombe après prepare et avant commit, les participants ne savent pas si commit ou abort a été décidé, et restent bloqués (locks tenus). En 1981, Dale Skeen a démontré qu'aucun protocole de commit atomique ne peut être à la fois non-bloquant et tolérant aux partitions, mais qu'on peut obtenir le non-blocage sous hypothèse synchrone (timing bornés et fail-stop). C'est exactement la promesse de 3PC.

Forces

• Coût supplémentaire : une round-trip de plus que 2PC (3 phases au lieu de 2).
• Hypothèse synchrone : 3PC suppose que tous les délais réseau sont bornés ; sinon il dégénère.
• Vulnérabilité aux partitions : split-brain possible si une partition isole le coordinateur et le quorum élit un nouveau coordinateur.
• Élection : nécessite un protocole d'élection sous-jacent (Bully, Raft) pour choisir le nouveau coordinateur.
• Complexité d'implémentation : très peu de SGBD du commerce l'implémentent réellement.

Solution

3PC insère une phase intermédiaire pre-commit entre prepare et commit. Phase 1 (canCommit) : le coordinateur demande si chaque participant peut commit ; chacun répond yes/no. Phase 2 (preCommit) : si tous ont dit yes, le coordinateur envoie preCommit ; chaque participant écrit pre-committed dans son journal et répond ACK. Phase 3 (doCommit) : le coordinateur envoie doCommit ; chaque participant fait le commit local et libère. L'astuce clé : un participant en état pre-committed sait que tous les autres ont voté yes ; en cas de crash du coordinateur, un protocole d'élection désigne un nouveau coordinateur qui peut conclure en doCommit sans risque, puisque l'abort est déjà exclu.

Structure

Coordinator                       Participants
    │                                  │
    │ Phase 1: canCommit? ──────────►  │
    │ ◄────────── yes/no ──────────────│
    │                                  │
    │ Phase 2: preCommit ───────────►  │  [write pre-committed]
    │ ◄──────────── ACK ────────────── │
    │                                  │
    │ Phase 3: doCommit ────────────►  │  [commit local]
    │ ◄──────────── ACK ────────────── │

If coordinator crashes between phase 2 and 3:
  Surviving participants run election (Bully / Raft)
  New coordinator queries each: "are you pre-committed?"
  If majority pre-committed → send doCommit
  Else → send abort
  → No participant remains blocked indefinitely (under synchronous assumption)

Implémentation EDI

3PC est principalement un objet académique : Oracle, PostgreSQL, IBM DB2 implémentent 2PC mais pas 3PC. Pour un hub EDI, on ne déploie pas 3PC ; on documente sa logique comme prérequis pour comprendre pourquoi les architectures modernes ont migré vers des sagas ou des protocoles de consensus (Raft, Paxos) qui résolvent le problème autrement. Un cas indirect : certaines plateformes de coordination distribuée comme Apache ZooKeeper utilisent une variante simplifiée (ZAB, ZooKeeper Atomic Broadcast) inspirée de la même idée d'éviter les états bloqués. Comprendre 3PC permet de mieux saisir les compromis CAP qu'un architecte EDI doit faire quand son hub doit coordonner plusieurs régions.

Anti-patterns

• Implémenter 3PC soi-même au lieu d'adopter un protocole moderne (Raft, Paxos) — la complexité est colossale et les cas d'usage rares.
• Croire que 3PC est « 2PC sans inconvénients » — il introduit la vulnérabilité aux partitions, ce qui est souvent pire.
• Ignorer l'hypothèse de synchronie — sur Internet, les bornes de délais ne sont pas garanties, et 3PC peut décider à tort.
• Mélanger 3PC et environnement géo-distribué — la latence inter-DC viole les bornes synchrones.

Patterns liés

• Two-Phase Commit (2PC) — l'origine ; 3PC tente d'en corriger le blocage.
• Paxos — alternative moderne au consensus distribué (Lamport 1989).
• Raft — version compréhensible de Paxos, adoptée largement.
• Leader Election — prérequis pour la phase de recovery de 3PC.

Sources

• Skeen D. — Nonblocking Commit Protocols, ACM SIGMOD 1981. Le papier fondateur. dl.acm.org
• Skeen D., Stonebraker M. — A Formal Model of Crash Recovery in a Distributed System, IEEE TSE 1983.
• Tanenbaum A., van Steen M. — Distributed Systems: Principles and Paradigms, 3rd ed., 2017, chap. 8.5 (« Atomic commit protocols »).
• Bernstein P., Newcomer E. — Principles of Transaction Processing, 2nd ed., Morgan Kaufmann, 2009.