Resumo

  • No Argus, o guardian reunia processos, objetos e responsabilidade de recuperação; a atomic action tornava serializáveis e integrais ou nulas as mudanças dos objetos recuperáveis participantes.
  • O commit não provava a conclusão de um equipamento externo, de uma tarefa humana ou de E/S não gerenciada. Também não identificava a pessoa nem validava o propósito de negócio por trás da chamada.

O commit fica verde, mas a máquina não se move

Imagine um handler que atualiza um objeto de controle durável e depois pede a um equipamento fora do Argus que execute uma ação. O topaction chega a uma decisão limpa. Todos os guardians participantes concordam. As novas versões dos objetos estáveis são registradas. O chamador recebe sucesso.

Ainda assim, a máquina continua parada.

Não há contradição. O Argus faz uma afirmação forte sobre os objetos recuperáveis inscritos na action e nenhuma sobre um dispositivo que não participou. “Commit” soa como conclusão absoluta. No trabalho de Barbara Liskov e da equipe Argus, era uma propriedade cuidadosamente delimitada pela linguagem e pelo runtime.

O artigo de 1983 Guardians and Actions, de Liskov e Robert Scheifler, combinou duas abstrações. O guardian agrupava os recursos, objetos e processos de um programa distribuído em um nó e assumia sua recuperação. A action agrupava operações que deveriam parecer seriais e produzir juntas o novo estado ou restaurar o estado recuperável anterior. A falha deixou de ser uma coleção de convenções improvisadas em cada aplicação.

O avanço também desenhou uma fronteira de evidência: o commit valia dentro do conjunto participante. Fora dele, era necessário outro recibo.

Um domínio de recuperação, não um guardião universal

O guardian se parecia com um módulo cuja vida ultrapassava a de um processo. Ele continha objetos, executava processos e expunha handlers a outros guardians. Após uma falha de nó, seu estado recuperável podia ser reconstruído; o estado volatile era reinicializado. A responsabilidade de recuperação ficava explícita.

O nome pode sugerir um monitor de segurança onisciente. É uma leitura ampla demais. O guardian encapsulava recursos do programa e recuperação, não cada arquivo, aparelho, pessoa ou serviço tocado pela organização.

O modelo de armazenamento mostra a diferença. Variáveis stable eram raízes para objetos resilient. Antes do commit de um topaction, o novo estado dos objetos estáveis modificados precisava chegar ao armazenamento estável. Variáveis voláteis eram reinicializadas na recuperação. Apontar uma variável stable para algo não resilient não transformava esse referente em estado transacional durável: o tipo do objeto e a implementação de recuperação continuavam decisivos.

Dizer que o Argus “tornava confiáveis os programas distribuídos” é impreciso. Ele tornava recuperável uma classe definida de estado sob hipóteses definidas de falha. A definição produzia a garantia.

Uma chamada de handler criava uma árvore de actions

O trabalho remoto não era um desvio invisível para fora da transação. Chamar o handler de outro guardian criava uma call action na origem e uma activation action no destino. Argumentos e resultados atravessavam a fronteira por valor, e o caminho de retorno participava do encerramento das subactions.

Um return ou signal comum normalmente confirmava a ativação. abort return e abort signal a abortavam. Assim, uma exceção não equivalia automaticamente a falha transacional. Se uma exceção devesse impedir o commit do trabalho envolvente, o programa precisava capturá-la na fronteira adequada.

Uma subaction podia abortar sem necessariamente derrubar o pai. Se confirmasse, seus bloqueios e versões provisórias subiam para o pai. O resultado continuava condicionado ao pai e, ao final, ao topaction. “Subaction confirmada” não significava “durável independentemente do chamador”.

O topaction era a raiz. No commit, o sistema coordenava os guardians, usava commit em duas fases quando a decisão distribuída exigia e registrava as novas versões dos objetos estáveis modificados pela action e por seus descendentes confirmados. Se abortasse, o estado administrado transacionalmente voltava à versão anterior.

A hierarquia impede três exageros: ativação bem-sucedida ainda não é commit do topaction; subaction confirmada não é independente; commit do topaction não prova nada sobre quem não participou.

Orphans expunham a ambiguidade da rede

A falha de uma chamada distribuída é ambígua. Um nó pode desaparecer enquanto o trabalho continua em outro lugar. O chamador pode perder o caminho de resposta sem saber se a ativação remota parou. O Argus chamava de orphan a action cujo ancestral morreu ou cujo resultado já não podia retornar à linhagem.

O mecanismo não era apenas um timeout. Buscava levar os orphans ao aborto e, sobretudo, impedir que observassem dados atômicos inconsistentes depois de perder a ascendência legítima. O manual preserva um fato incômodo: um resultado unavailable no chamador pode coexistir com atividade remota ainda executando como orphan.

Duas conclusões são perigosas. Não receber resposta não prova que nada executou. Forçar aborto dentro do sistema de actions não prova a reversão de um efeito externo não gerenciado. A garantia depende de as actions se comunicarem por dados atômicos. Um pulso de motor, uma página impressa, um e-mail já entregue ou uma instrução humana não voltam no tempo porque um ancestral Argus desapareceu.

O Argus resolveu um problema difícil definindo o estado que podia controlar, não fingindo que o mundo inteiro era transacional.

Open nesting era uma exceção deliberada

Subactions comuns continuavam condicionadas pelo pai. O Argus também oferecia nested topaction, capaz de confirmar de forma independente e sobreviver mesmo se a action externa abortasse depois. Era open nesting.

Isso servia para efeitos que deveriam permanecer, como um registro de coordenação deliberadamente durável, mas mudava a prova. O programador precisava garantir que o efeito independente fosse seguro após a falha do pai e respeitasse as restrições de serialização. Sua permanência não era um vazamento misterioso de atomicidade; era uma exceção explícita ao domínio de rollback.

Padrões atuais de outbox, etapa de saga ou escrita de auditoria independente reencontram essa forma. O efeito confirmado separadamente deve ser identificado, nunca escondido numa afirmação de que o pai foi revertido sem resíduos.

O commit resolvia estado, não identidade ou intenção

A identidade da action ligava concorrência e recuperação. Não autenticava uma pessoa. Um handler podia conhecer argumentos, resultados e ascendência sem saber qual funcionário ou responsável concedeu o mandato de negócio.

Serialização tampouco é limitação de finalidade. Duas solicitações podem ser igualmente válidas para a interface, mas só uma ter aprovação. Uma atualização tudo-ou-nada pode preservar o invariante interno e violar uma regra que atravesse rede de pagamentos, processo físico ou organização. Não é falha do modelo; é um motivo para não exigir dele uma resposta que nunca prometeu.

A evidência operacional deve ser organizada em camadas. O registro transacional descreve guardians, objetos recuperáveis, encerramentos das subactions, decisão e gravação estável. O registro de identidade descreve o principal de execução e, quando necessário, a pessoa que iniciou ou aprovou. Recibos externos confirmam outro serviço, aparelho ou processo humano. Um invariante mais amplo exige observações em todos os domínios relevantes.

O crédito científico também tem fronteiras

Liskov é o ponto de entrada natural: liderou o programa e escreveu a síntese madura de 1988. Mas Argus foi trabalho coletivo. Guardians and Actions é de Barbara Liskov e Robert Scheifler e agradece ao grupo de projeto, especialmente Maurice Herlihy, Paul Johnson e William Weihl. O manual de 1987 nomeia Liskov, Mark Day, Herlihy, Johnson, Gary Leavens, Scheifler e Weihl. O artigo de implementação reúne Liskov, Dorothy Curtis, Johnson e Scheifler.

Preservar esses nomes não é cerimônia. A fronteira entre ideia de linguagem, protocolo de recuperação, manual e implementação operacional faz parte da história técnica. Um nome célebre não deve absorver o trabalho do sistema inteiro, assim como um commit não absorve os resultados do mundo inteiro.

Fontes