Resumen

  • En Argus, un guardian encerraba procesos, objetos y responsabilidad de recuperación; una atomic action hacía serializables y totales o nulos los cambios de los objetos recuperables participantes.
  • El commit no probaba que terminara un dispositivo externo, una tarea humana o una E/S no administrada. Tampoco identificaba a la persona ni validaba el propósito empresarial de una llamada.

El commit sale bien y la máquina permanece quieta

Imaginemos un handler que actualiza un objeto de control duradero y después pide actuar a un equipo situado fuera de Argus. El topaction toma una decisión limpia. Todos los guardians participantes coinciden. Las nuevas versiones de los objetos estables quedan registradas. El llamante recibe éxito.

Sin embargo, el equipo no se mueve.

No hay contradicción. Argus formula una garantía fuerte sobre los objetos recuperables incorporados a la action y ninguna sobre un dispositivo no incorporado. «Commit» suena a final absoluto, pero en el trabajo de Barbara Liskov y el equipo de Argus era una propiedad cuidadosamente delimitada del lenguaje y el runtime.

El artículo de 1983 Guardians and Actions, firmado por Liskov y Robert Scheifler, unió dos abstracciones. El guardian reunía los recursos, objetos y procesos de un programa distribuido en un nodo y asumía su recuperación. La action reunía operaciones que debían parecer seriales y producir juntas el nuevo estado o restaurar el estado recuperable anterior. El fallo dejaba de ser una colección de convenciones improvisadas por cada aplicación.

Ese avance también marcó una frontera probatoria: el commit tenía autoridad dentro del conjunto participante. Fuera de él hacía falta otro comprobante.

Un dominio de recuperación, no un vigilante universal

El guardian se parecía a un módulo cuya vida superaba la de un proceso. Albergaba objetos, ejecutaba procesos y exponía handlers a otros guardians. Tras la caída de un nodo podía restaurar el estado recuperable; el estado volatile se inicializaba de nuevo. La responsabilidad de recuperación quedaba localizada.

El nombre puede sugerir un monitor de seguridad omnisciente. Sería una lectura excesiva. El guardian encapsulaba recursos del programa y recuperación, no todo archivo, aparato, persona o servicio con el que tratara la organización.

El modelo de almacenamiento muestra la diferencia. Las variables stable servían como raíces de objetos resilient. Antes del commit del topaction, el nuevo estado de los objetos estables modificados debía llegar al almacenamiento estable. Las variables volátiles se reinicializaban durante la recuperación. Apuntar desde una variable stable a algo no resilient no lo convertía por arte de magia en estado transaccional duradero: seguían importando el tipo y la implementación de recuperación.

Decir que Argus «hacía fiables los programas distribuidos» es demasiado general. Hacía recuperable una clase definida de estado bajo supuestos definidos de fallo. La definición producía la garantía.

Una llamada a handler construía un árbol de actions

El trabajo remoto no era un desvío invisible fuera de la transacción. Llamar al handler de otro guardian creaba un call action en el origen y un activation action en el destino. Los argumentos y resultados cruzaban por valor; la ruta de retorno intervenía en el final de las subactions.

Un return o signal normal solía confirmar la activación. abort return y abort signal la abortaban. Por tanto, una excepción no equivalía automáticamente al fallo transaccional. Si una excepción debía impedir el commit del trabajo envolvente, el programa tenía que capturarla en la frontera adecuada.

Una subaction podía abortar sin derribar necesariamente al padre. Si confirmaba, sus bloqueos y versiones provisionales pasaban al padre. El resultado seguía condicionado por el padre y, en último término, por el topaction. «Subaction confirmada» no quería decir «duradera con independencia del llamante».

El topaction era la raíz. Al confirmarlo, el sistema coordinaba a los guardians, usaba commit de dos fases cuando la decisión distribuida lo requería y registraba las versiones nuevas de los objetos estables modificados por la action y sus descendientes confirmados. Si abortaba, el estado administrado transaccionalmente volvía a su versión previa.

La jerarquía impide tres exageraciones: una activación exitosa aún no es el commit del topaction; una subaction confirmada no es independiente; el commit del topaction no prueba nada sobre quien no participó.

Los orphans mostraban la ambigüedad de la red

El fallo de una llamada distribuida es ambiguo. Un nodo puede desaparecer mientras el trabajo sigue en otro lugar. El llamante puede perder la ruta de respuesta sin saber si se detuvo la activación remota. Argus llamaba orphan a una action cuyo ancestro había muerto o cuyo resultado ya no podía volver a su linaje.

El mecanismo de huérfanos no era un simple timeout. Buscaba que acabaran abortando y, sobre todo, que no observaran datos atómicos incoherentes después de perder su ascendencia legítima. El manual conserva un hecho incómodo: un resultado unavailable en el llamante puede coexistir con actividad remota que aún se ejecuta como orphan.

Dos deducciones son peligrosas. No recibir respuesta no prueba que nada se ejecutó. Forzar el aborto dentro del sistema de actions no prueba que un efecto externo no administrado se revirtiera. La garantía depende de que las actions se comuniquen mediante datos atómicos. Un impulso a un motor, una página impresa, un correo ya entregado o una instrucción humana no retroceden porque desaparezca un ancestro Argus.

Argus resolvió un problema difícil definiendo el estado que podía controlar, no fingiendo que todo el mundo era transaccional.

El open nesting era una excepción deliberada

Las subactions ordinarias seguían condicionadas por su padre. Argus también ofrecía un nested topaction, capaz de confirmar de forma independiente y sobrevivir aunque la action envolvente abortara después. Era open nesting.

Servía para efectos que debían permanecer, como un registro de coordinación deliberadamente duradero, pero cambiaba la prueba. El programador debía garantizar que el efecto independiente resultara seguro tras el fallo del padre y respetara las restricciones de serialización. Su permanencia no era una fuga misteriosa de atomicidad, sino una excepción explícita al dominio de rollback.

Los patrones actuales de outbox, pasos de saga o escrituras de auditoría independientes redescubren esa forma. El nombre importa menos que la disciplina: un efecto confirmado por separado debe declararse y no esconderse dentro de una afirmación de que el padre se revirtió sin restos.

El commit resolvía estado, no identidad ni intención

La identidad de una action enlazaba trabajo de concurrencia y recuperación. No autenticaba a una persona. Un handler podía conocer argumentos, resultados y ascendencia sin saber qué empleado o responsable había concedido el mandato empresarial.

La serialización tampoco limita la finalidad. Dos solicitudes pueden ser igualmente válidas para la interfaz del objeto mientras solo una cuenta con una aprobación. Una actualización todo-o-nada puede conservar el invariante interno y violar una regla que abarque una red de pagos, un proceso físico o una organización. No es un defecto del modelo: es una razón para no pedirle una respuesta que nunca prometió.

La evidencia operativa debe ir por capas. El registro transaccional describe guardians, objetos recuperables, finales de subactions, decisión y escritura estable. El registro de identidad describe el principal de ejecución y, cuando corresponda, la persona que inició o aprobó. Los comprobantes externos confirman otro servicio, un aparato o un proceso humano. Un invariante más amplio exige observaciones en todos sus dominios.

El crédito científico también tiene fronteras

Liskov es la entrada natural porque lideró el programa y escribió la síntesis madura de 1988. Argus, no obstante, fue un trabajo colectivo. Guardians and Actions pertenece a Barbara Liskov y Robert Scheifler y agradece al grupo de diseño, en especial a Maurice Herlihy, Paul Johnson y William Weihl. El manual de 1987 nombra a Liskov, Mark Day, Herlihy, Johnson, Gary Leavens, Scheifler y Weihl. El artículo de implementación suma a Dorothy Curtis junto a Liskov, Johnson y Scheifler.

Conservar esos nombres no es ceremonial. La frontera entre idea lingüística, protocolo de recuperación, manual e implementación funcional forma parte de la historia técnica. Un nombre célebre no debe absorber el trabajo del sistema entero, del mismo modo que un commit no absorbe el resultado del mundo entero.

Fuentes