Résumé

  • Le RFC 2372 recommandait de créer un enregistrement de récupération avant PREPARED, puis un autre avant COMMIT lorsque la transaction était Prepared, et de ne les supprimer qu’après des réponses précisément nommées.
  • Cette chronologie décrivait une obligation locale durable ; elle ne prouvait ni l’écriture sur un support stable, ni la survie à une panne, ni la reconstruction du bon identifiant, ni la connaissance du résultat par l’application.

PREPARED paraît moins définitif que COMMIT. C’est justement ce qui le rend trompeur. Tant qu’un participant n’est pas préparé, une défaillance peut encore conduire à l’abandon. Dès qu’il a envoyé PREPARED, il ne dispose plus de cette liberté : le coordinateur peut avoir reçu tous les votes et choisi la validation. Le participant a promis d’attendre et d’obéir, même si le dialogue réseau qui portait la promesse s’évanouit.

Le RFC 2372 rendait cette promesse observable par un ordre d’écriture. Le subordonné devait créer un prepared-recovery record avant d’envoyer PREPARED. Il devait le garder jusqu’à ABORT, COMMIT ou QUERIEDNOTFOUND, et ne pas répondre COMMITTED ou NOTRECONNECTED tant que cet enregistrement subsistait. Le supérieur, après avoir reçu PREPARED, devait créer un commit-recovery record avant d’envoyer COMMIT dans l’état Prepared, puis le conserver jusqu’à COMMITTED ou NOTRECONNECTED.

Ce n’était pas une simple recommandation de « journaliser les événements importants ». L’enregistrement matérialisait la garde d’une obligation. PREPARED retirait au participant le droit de choisir seul. COMMIT obligeait le supérieur à pouvoir répéter une décision après une interruption. Supprimer la trace revenait à affirmer qu’une preuve de résolution expressément prévue avait clos cette obligation.

Deux rôles, deux séries de reçus

Les signaux autorisant la suppression étaient asymétriques parce que les deux rôles ne savaient pas la même chose. Pour le subordonné, ABORT ou COMMIT apportait la décision ; QUERIEDNOTFOUND indiquait que le supérieur ne détenait plus la transaction présumée abandonnée. Pour le supérieur, COMMITTED confirmait l’exécution, tandis que NOTRECONNECTED pouvait signifier que le subordonné avait déjà validé, répondu, puis oublié son état achevé.

L’absence n’avait donc aucun sens isolé. Elle devait être lue avec le rôle, l’état précédent, l’identifiant et la séquence des messages. Une ligne manquante pouvait signaler une fin correcte, un abandon présumé ou une perte de preuve. Un opérateur ne pouvait pas choisir entre ces interprétations à partir d’un simple écran « connexion rétablie ».

Après une coupure, le supérieur envoyait RECONNECT avec l’identifiant de transaction du subordonné, éventuellement retrouvé dans son journal. Un subordonné encore Prepared répondait RECONNECTED. Dans l’autre sens, QUERY permettait au subordonné d’interroger le supérieur ; QUERIEDEXISTS annonçait une reconnexion ultérieure, QUERIEDNOTFOUND autorisait l’abandon. TCP rétablissait un chemin de conversation, pas l’identité ni l’histoire nécessaires à la récupération.

Les temporisations locales limitaient l’indisponibilité des ressources et contribuaient à résoudre les interblocages. Elles ne constituaient pas un reçu de décision. Le temps écoulé pouvait justifier une action locale prévue par la politique, jamais transformer une supposition en connaissance du résultat.

« Créer » n’était pas encore « rendre durable »

Le texte était une RFC Informational, non une norme Internet, et qualifiait d’indicatives ses relations entre protocole et journal. Il ne décrivait ni produit déployé, ni moteur de stockage, ni campagne d’injection de pannes. Cette limite interdit de convertir une prescription écrite en constat de fonctionnement.

Dans une pile réelle, « créer un enregistrement » ouvre une série de questions. Les octets sont-ils restés dans un tampon utilisateur, passés dans le cache du noyau, inscrits dans un journal, forcés sur le support, ou répliqués hors du domaine de panne ? L’accusé de stockage possède-t-il vraiment une sémantique de persistance ? Une coupure peut-elle déchirer l’écriture ? L’identifiant reste-t-il retrouvable si l’index volatil disparaît ? L’émetteur asynchrone peut-il faire partir PREPARED avant la fin de l’écriture ?

Le regard de Heng Lu qui accorde la primauté au code en fonctionnement clarifie le partage. La spécification peut établir la chronologie à respecter. La preuve opérationnelle exige d’observer l’écriture, d’interrompre le système au moment défavorable, de redémarrer, de retrouver la même transaction, de se réconcilier avec le pair et de vérifier l’état de la ressource. Le RFC donne une forme au test ; il ne fournit pas son résultat.

La suppression requiert la même prudence. Attendre le bon message ne suffit pas si l’effacement devient durable avant la transition correspondante du gestionnaire de ressources. Garder indéfiniment toutes les traces peut être sûr mais rendre les ressources et l’exploitation intenables. La correction se trouve dans la relation vérifiable entre état du protocole, état du journal et état de la ressource.

La délégation déplaçait la responsabilité

Un client léger pouvait déléguer la coordination à un serveur complet et ne conserver aucun journal de transaction. Cette économie locale ne supprimait pas la dette de récupération. Elle désignait simplement un autre gardien. L’audit devait suivre la promesse jusqu’au serveur : quel objet avait été écrit, sous quel identifiant, avant quel message, puis détruit après quelle réponse ?

Le résultat connu du client formait encore une autre couche. Une application pouvait demander commit, perdre la réponse finale et découvrir plus tard que la transaction avait abouti. Le RFC 2372 lui laissait la charge d’établir le résultat et évoquait un journal utilisateur propre à l’implémentation. Une récupération protocolaire réussie ne produisait donc pas automatiquement une réponse métier pour l’appelant.

Cette limite distingue le présent sujet de l’article déjà consacré au RFC 2371. Celui-ci examinait les deux canaux et le fait que COMMIT n’est pas un reçu commercial. Ici, la question est la chaîne de garde sous la reprise : enregistrement prepared du participant, enregistrement commit du supérieur, identifiant retrouvé, message distant qui autorise enfin l’effacement.

Les deux canaux imposaient aussi une discipline à l’application. Le gestionnaire TIP ne voyait pas nécessairement les requêtes applicatives encore en vol. L’application ne devait pas lancer commit avant leur achèvement, ni répondre positivement à une requête transactionnelle avant l’enregistrement local de la transaction. Un journal parfait ne pouvait pas corriger un ensemble d’opérations métier incomplet ou une réponse partie trop tôt.

Authentifier le pair ne prouvait pas son journal

Le RFC plaçait l’authentification et l’autorisation applicatives hors de TIP. TLS pouvait authentifier les extrémités et chiffrer les commandes, selon négociation. Cette protection répondait à l’usurpation d’un gestionnaire de transactions ; elle ne prouvait pas la persistance du journal, l’autorisation métier, l’effet sur la ressource ou la reconnaissance du résultat par un autre système.

Une reprise avait besoin à la fois d’un canal digne de confiance et du bon identifiant. Une requête authentifiée visant la mauvaise transaction restait erronée ; un bon identifiant offert par un imposteur restait dangereux. Identité de sécurité, état du protocole et pouvoir métier constituaient des preuves complémentaires, non interchangeables.

La lecture par « couches de réalité » évite alors un raccourci fréquent. Requête applicative, action locale, état TIP, enregistrement, accusé du stockage, message réseau, identité reconstruite, réponse du pair, résultat de la ressource et connaissance du client sont liés sans être identiques. Une couche peut être certaine tandis que la suivante demeure inconnue. Les réduire au mot « validé » fabrique de la confiance plus vite que des faits.

Une spécification minimale, une charge locale de preuve

Le RFC 2372 ne prescrivait ni format universel de journal, ni base de données, ni API. L’interopérabilité exigeait des commandes, des rôles, des identifiants et une signification commune de la reprise, pas le même stockage. Selon la logique de spécification initiale minimale de Heng Lu, la décision future restait localisée chez chaque implémentation.

Cette liberté avait un prix : l’implémentation devait démontrer comment elle rendait l’enregistrement durable, le liait à la ressource, exposait l’ambiguïté et testait la panne. Pointer vers le texte ne suffisait pas. Il fallait demander si la preuve précédait vraiment le message, survivait à une perte de courant, restait indexable après le redémarrage et n’était effacée qu’au reçu exact.

Les systèmes distribués contemporains parlent encore avant de tomber : « accepté », « répliqué », « prêt », « autorisé ». Chacun de ces mots crée une attente sur ce qui subsistera après la panne. La leçon historique du RFC 2372 n’est pas qu’un journal rend la parole vraie. Elle est qu’une parole aux conséquences durables exige, derrière elle, une preuve inspectable, persistante et correctement ordonnée.

Sources