Resumo

  • O RFC 2372 recomendou criar um prepared-recovery record antes de PREPARED e um commit-recovery record antes de COMMIT no estado Prepared, mantendo cada um até a evidência de resolução indicada.
  • A ordem estabelecia custódia local, mas não comprovava gravação estável, sobrevivência à falha, reconstrução da identidade correta nem conhecimento do desfecho pela aplicação.

PREPARED soa provisório. No entanto, é o instante em que um participante perde a liberdade de simplesmente abortar após uma falha. O superior pode já ter reunido os votos e escolhido confirmar. Ao pronunciar essa palavra, o subordinado promete que lembrará a transação quando o processo, a máquina ou a conversa de rede já não forem os mesmos.

Publicado em julho de 1998, o RFC 2372 era Informational, não um padrão da Internet. Ele descrevia cenários, requisitos e informações complementares sobre TIP, e chamava sua correspondência entre protocolo e log de orientação, não de definição final. Não apresentava produto, implantação, banco de dados ou teste de queda. O que fornecia era uma sequência que uma implementação ainda teria de tornar real.

O subordinado deveria criar o registro prepared antes de enviar PREPARED e mantê-lo até ABORT, COMMIT ou QUERIEDNOTFOUND. Enquanto o registro existisse, não deveria responder COMMITTED nem NOTRECONNECTED. O superior, depois de receber PREPARED, deveria criar seu registro commit antes de enviar COMMIT e conservá-lo até COMMITTED ou NOTRECONNECTED.

Essas regras descreviam transferências de custódia. PREPARED transformava uma escolha local em dever perante o coordenador. COMMIT transformava uma decisão do superior em algo que talvez precisasse ser repetido. Excluir o registro significava afirmar que a evidência prevista encerrara o dever; não era mera limpeza.

A recuperação dependia da história, não só da conexão

Após perder a conexão, o superior podia enviar RECONNECT com o identificador da transação subordinada, recuperado do log quando necessário. Se ainda estivesse Prepared, o subordinado respondia RECONNECTED. Se já tivesse recebido COMMIT, respondido COMMITTED e esquecido o estado concluído, dizia NOTRECONNECTED. Uma resposta negativa podia, dentro da sequência correta, ser prova de conclusão.

O subordinado podia enviar QUERY. QUERIEDEXISTS dizia que o superior ainda conhecia a transação e reconectaria depois. QUERIEDNOTFOUND permitia abortar: o superior podia ter enviado ABORT, perdido ABORTED e esquecido a transação presumidamente abortada. Ausência só ganhava sentido com papel, estado, identidade e histórico de mensagens.

Uma sessão TCP restaurada não fornecia essas quatro coisas. Transporte fazia os extremos conversarem novamente, mas não dizia qual transação sobrevivera, quem ainda devia agir ou se um registro ausente representava fim seguro, aborto presumido ou perda. A memória local durável precisava encontrar uma evidência remota compatível.

Os recibos de exclusão eram diferentes para cada papel. O subordinado aguardava decisão ou consulta que liberasse o estado prepared; o superior aguardava confirmação do participante ou o caso específico em que ele já havia concluído e esquecido. Reinício, falta de disco, expiração ou confiança do operador não apareciam como substitutos.

Timeouts locais podiam limitar recursos indisponíveis e resolver deadlocks. Tempo decorrido, porém, não provava o resultado. Liberar um recurso, encerrar o protocolo e saber o que ocorreu continuavam sendo fatos distintos.

Entre criar e persistir havia uma fronteira não especificada

Onde termina a criação de um registro? No buffer do processo, no cache do kernel, no journal, no meio físico ou em uma réplica em outro domínio de falha? O reconhecimento do armazenamento promete durabilidade? A escrita pode ficar parcial? O identificador pode ser reencontrado sem um índice volátil? Um emissor assíncrono pode mandar PREPARED cedo demais?

O RFC não respondia a isso. Sua exigência escrita não era observação de uma implementação. Pela lente de Heng Lu que dá primazia ao código em funcionamento, o texto define o que deve ser testado: observar a gravação durável, interromper no pior instante, reiniciar, reconstruir a mesma identidade, reconciliar com o par e verificar o recurso. A especificação desenha o experimento; não entrega aprovação.

A exclusão também pode estar ordenada de modo errado. Mesmo depois da mensagem autorizada, apagar antes de tornar durável a mudança do gerenciador de recursos cria outra inconsistência. Nunca apagar preserva prova, mas pode prender recursos e operação. Correção está na relação verificável entre estado do protocolo, log e recurso.

Delegar trocava o guardião

Um cliente leve podia delegar coordenação a um servidor completo e não manter log próprio. Isso não eliminava a responsabilidade de recuperação. O servidor passava a guardá-la. Uma auditoria deveria seguir a obrigação: qual registro foi criado, sob qual identificador, antes de qual mensagem e removido depois de qual recibo.

O cliente ainda podia perder a resposta final de commit e não saber que a transação terminara. O RFC deixou à aplicação a tarefa de descobrir o desfecho e sugeriu que um log de usuário específico poderia ajudar. O gerenciador podia recuperar perfeitamente seu estado, enquanto quem iniciou o trabalho permanecia sem resposta comercial.

É esse encadeamento local que separa o artigo do texto já publicado sobre RFC 2371. Aquele tratou dos dois canais e de COMMIT não ser recibo de negócio. Aqui importam o registro prepared, o registro commit, a identidade recuperada e o sinal preciso que autoriza cada desaparecimento.

Os dois canais ainda exigiam serialização pela aplicação. O gerenciador TIP talvez não enxergasse requisições ainda em trânsito. A aplicação não deveria iniciar commit antes que terminassem, nem responder positivamente a um parceiro antes do registro local. Um log impecável não corrigia uma decisão tomada sobre operações incompletas.

Segurança, estado e autoridade não eram a mesma prova

Autenticação e autorização de aplicação ficavam fora de TIP. TLS podia autenticar extremos e cifrar comandos quando negociado. Isso protegia contra comandos não autorizados e falsos gerenciadores, mas não provava que o par persistira o registro, que o pedido fora autorizado, que o recurso mudara ou que o negócio reconhecera o resultado.

Recuperação precisava de canal confiável e identidade correta. Uma solicitação autenticada para a transação errada continuava errada; o identificador certo vindo de um impostor continuava perigoso. Evidência de segurança, de estado e de autoridade se complementavam.

A lente de camadas de realidade de Heng Lu impede a fusão de pedido, ação local, estado TIP, registro, confirmação de armazenamento, mensagem, identidade reconstruída, resposta do par, resultado do recurso e conhecimento do cliente. Uma camada pode estar confirmada enquanto a seguinte continua desconhecida.

A especificação mínima preservou a escolha — e a cobrança

O RFC não impôs formato de log, motor, API ou console. Interoperabilidade exigia comandos, papéis, identificadores e semântica de recuperação compartilhados, não o mesmo banco. Pela ideia de especificação inicial mínima de Heng Lu, decisões futuras permaneceram locais.

Essa liberdade aumentou a obrigação de evidência. O operador precisava mostrar que o registro precedia a mensagem, sobrevivia à energia perdida, reaparecia sem índices voláteis, ligava-se ao recurso certo e só sumia com o recibo permitido. Apontar para o RFC dizia qual era a obrigação, não se ela fora cumprida.

Sistemas atuais ainda dizem “aceito”, “replicado”, “pronto” e “autorizado” antes de falhar. Cada palavra promete algo sobre o que restará. A lição do RFC 2372 não é que a existência de um log torna a fala verdadeira. É que toda fala com efeitos pós-falha precisa de prova durável, inspecionável e anterior.

Fontes