Résumé

  • Dans Argus, le guardian enfermait processus, objets et responsabilité de reprise ; l'action atomique rendait les changements des objets récupérables participants sérialisables et indivisibles.
  • Un commit ne prouvait pas l'exécution d'un équipement externe, d'une procédure humaine ou d'une E/S non gérée. Il n'établissait pas davantage l'identité humaine ou le mandat métier derrière l'appel.

Le commit est vert, la machine reste immobile

Imaginons un handler qui modifie un objet de commande durable, puis demande à un équipement extérieur à Argus d'agir. Le topaction obtient une décision nette. Tous les guardians participants s'accordent. Les nouvelles versions des objets stables sont enregistrées. Le succès revient à l'appelant.

Et pourtant, la machine ne bouge pas.

Il n'y a aucune contradiction. Argus formule une garantie forte sur les objets récupérables enrôlés dans l'action, mais aucune sur un appareil non enrôlé. Le mot « commit » donne une impression d'achèvement absolu. Chez Barbara Liskov et l'équipe Argus, il désignait au contraire une propriété précisément bornée par le langage et son exécution.

L'article de 1983 Guardians and Actions, signé par Liskov et Robert Scheifler, associait deux abstractions. Le guardian réunissait les ressources, objets et processus d'un programme distribué sur un nœud et portait leur reprise. L'action réunissait les opérations qui devaient paraître sérielles et soit produire ensemble leur nouvel état, soit restaurer l'ancien état récupérable. Les pannes cessaient ainsi d'être une collection de conventions improvisées dans chaque application.

Ce progrès dessinait aussi une frontière de preuve : le commit faisait autorité dans l'ensemble des participants. Au-delà, il fallait un autre reçu.

Un domaine de reprise, pas un gardien universel

Un guardian ressemblait à un module dont la vie dépassait celle d'un processus. Il contenait des objets, lançait des processus et exposait des handlers à d'autres guardians. Après une panne de nœud, son état récupérable pouvait être reconstruit, tandis que son état volatile était réinitialisé. La responsabilité de reprise devenait explicite.

Le nom peut suggérer un contrôleur de sécurité omniscient. Ce serait excessif. Le guardian encapsulait les ressources du programme et leur récupération, pas chaque fichier, personne, appareil ou service touché par l'organisation.

La différence apparaît dans le stockage. Les variables stables formaient des racines vers des objets résilients. Avant le commit d'un topaction, le nouvel état des objets stables modifiés devait atteindre le stockage stable. Les variables volatiles étaient réinitialisées lors de la reprise. Une référence placée dans une variable stable ne transformait pas magiquement un objet non résilient en état transactionnel durable : le type de l'objet et son mécanisme de reprise restaient décisifs.

Dire qu'Argus « rendait les programmes distribués fiables » est donc trop vague. Il rendait récupérable une classe définie d'états, sous des hypothèses de panne définies. C'est la définition qui produisait la garantie.

L'appel de handler faisait pousser un arbre d'actions

Le travail distant n'était pas une excursion invisible hors de la transaction. Un appel vers le handler d'un autre guardian créait un call action chez l'appelant et un activation action chez la cible. Arguments et résultats franchissaient la frontière par valeur ; le retour participait à la fin des sous-actions.

Un return ou signal ordinaire validait normalement l'activation. abort return et abort signal l'annulaient. Une exception n'était donc pas automatiquement l'équivalent d'un échec transactionnel. Si une exception devait empêcher la validation du travail englobant, le programme devait la capturer au bon niveau de l'action.

Une sous-action pouvait échouer sans détruire nécessairement son parent. Lorsqu'elle validait, ses verrous et versions provisoires remontaient vers le parent. Son résultat restait conditionnel au parent, puis au topaction. « Sous-action validée » ne signifiait pas « durable indépendamment de l'appelant ».

Le topaction constituait la racine. À sa validation, le système coordonnait les guardians participants, employait le commit en deux phases lorsque la décision distribuée l'exigeait et enregistrait les nouvelles versions des objets stables modifiés par l'action et ses descendants validés. En cas d'abandon du topaction, l'état géré par la transaction revenait à sa version antérieure.

Cette hiérarchie évite trois glissements : une activation réussie n'est pas encore un commit du topaction ; une sous-action validée n'est pas indépendante ; le commit du topaction ne prouve rien sur un non-participant.

Les orphelins révélaient l'ambiguïté du réseau

L'échec d'un appel distribué est ambigu. Un nœud peut disparaître alors que le travail continue ailleurs. L'appelant peut perdre la voie de retour sans savoir si l'activation distante s'est arrêtée. Argus appelait orphan une action dont l'ancêtre avait péri ou dont le résultat ne pouvait plus rejoindre sa lignée.

Le dispositif d'orphelins n'était pas un simple délai d'attente. Il cherchait à provoquer leur abandon et, surtout, à empêcher qu'ils observent des données atomiques incohérentes après la disparition de leur ascendance légitime. Le manuel conserve un fait opérationnel essentiel : un résultat unavailable chez l'appelant peut coexister avec une activité distante encore en cours comme orpheline.

Deux conclusions sont donc dangereuses. Ne pas recevoir de résultat ne prouve pas que rien ne s'est exécuté. Forcer l'abandon dans le système d'actions ne prouve pas qu'un effet externe non géré a été retiré. La garantie dépend des communications par données atomiques. Une impulsion de moteur, une page imprimée, un courriel déjà remis ou une instruction humaine ne remontent pas le temps parce qu'un ancêtre Argus a disparu.

Argus a résolu un problème difficile en définissant l'état qu'il contrôlait, pas en déclarant le monde entier transactionnel.

L'imbrication ouverte était une exception choisie

Les sous-actions ordinaires restaient conditionnelles au parent. Argus proposait aussi un nested topaction, capable de valider indépendamment et de survivre à l'abandon ultérieur de l'action englobante. C'était une forme d'imbrication ouverte.

Cette capacité convenait aux effets qui devaient subsister, telle une trace de coordination voulue. Mais elle changeait la preuve. Le programmeur devait s'assurer que l'effet indépendant restait sûr après l'échec du parent et respectait les contraintes de sérialisation. Sa persistance n'était pas une fuite mystérieuse de l'atomicité ; c'était une exception explicite au domaine d'annulation.

Les motifs modernes d'outbox, d'étape de saga ou d'écriture d'audit indépendante retrouvent cette structure. L'effet validé séparément doit être nommé comme tel, jamais dissimulé dans une affirmation selon laquelle le parent aurait été annulé sans reste.

L'état n'est ni l'identité ni l'intention

L'identité d'action reliait le travail de concurrence et de reprise. Elle n'authentifiait pas une personne. Un handler pouvait connaître les arguments, résultats et ancêtres d'action sans savoir quel salarié ou responsable avait donné le mandat métier.

La sérialisabilité n'est pas non plus une limitation de finalité. Deux requêtes peuvent être également valides pour l'interface de l'objet alors qu'une seule dispose d'une approbation. Une mise à jour atomique peut préserver l'invariant interne d'un objet et violer une règle qui traverse un réseau de paiement, un procédé physique ou une organisation. Le modèle n'est pas fautif ; il faut simplement cesser de lui poser une question qu'il ne promet pas de résoudre.

La preuve opérationnelle doit donc être stratifiée. Le registre transactionnel décrit les guardians et objets récupérables, la fin des sous-actions, la décision finale et l'écriture stable. Le registre d'identité décrit le principal d'exécution et, si nécessaire, la personne qui a initié ou approuvé. Les reçus externes constatent l'achèvement d'un autre service, d'un appareil ou d'un processus humain. Un invariant plus large exige une observation de tous ses domaines.

Le mérite scientifique a lui aussi une frontière

Liskov est l'entrée naturelle : elle a dirigé le programme et signé la synthèse de 1988. Argus reste un travail collectif. Guardians and Actions est de Barbara Liskov et Robert Scheifler et remercie le groupe de conception, notamment Maurice Herlihy, Paul Johnson et William Weihl. Le manuel de 1987 nomme Liskov, Mark Day, Herlihy, Johnson, Gary Leavens, Scheifler et Weihl. L'article d'implémentation réunit Liskov, Dorothy Curtis, Johnson et Scheifler.

Conserver ces noms n'est pas cérémoniel. La distinction entre idée de langage, protocole de reprise, manuel et système exécuté appartient à l'histoire technique. Un nom célèbre ne doit pas absorber l'œuvre collective, pas plus qu'un commit ne doit absorber les résultats du monde entier.

Sources