Resumo

  • A RFC 2371 padronizou um acordo em duas fases entre gerenciadores de transação, não o transporte, a autorização nem a confirmação das solicitações de negócio.
  • PREPARED e COMMITTED eram provas operacionais fortes, porém limitadas: não demonstravam que todo o trabalho esperado havia sido incluído nem que o chamador recebeu o desfecho.

Dois canais, duas autoridades

Publicada em julho de 1998, a RFC 2371 descreveu o Transaction Internet Protocol, ou TIP, como um protocolo simples de confirmação em duas fases. O conteúdo da transação — compra, reserva ou transferência — passava por um protocolo da aplicação. Em outro canal, os gerenciadores participantes combinavam se o conjunto seria confirmado ou abortado. O documento chamou esse arranjo de modelo de “dois canais”.

Era uma escolha econômica. O TIP não precisava normalizar a representação de dados de cada setor. Sistemas existentes mantinham suas mensagens e compartilhavam apenas uma linguagem curta de coordenação. A especificação tampouco prometia substituir todos os protocolos de confirmação já usados.

A mesma separação delimitava a prova. Um gerenciador podia responder COMMITTED sem saber se o cliente recebeu a confirmação, se uma chamada planejada nunca foi enviada ou se a aplicação desenhou a unidade de trabalho de forma incompleta. A coerência do canal de coordenação não consertava uma lacuna no canal de negócio.

A aplicação escolhia a borda da transação

No exemplo de compras, um gerenciador local e vários remotos entram no mesmo conjunto para confirmar pedidos em conjunto. O TIP oferece atomicidade aos participantes efetivamente alistados. Cabe à aplicação decidir quais operações pertencem ao conjunto e quando pedir COMMIT.

A RFC 2372 torna essa obrigação explícita. Em um modelo com dois canais, o TIP nem sempre consegue impor a serialização das mensagens da aplicação. Não se deve iniciar a confirmação enquanto houver solicitações pendentes, nem anunciar sucesso antes do registro no gerenciador local. Um participante esperado, mas nunca alistado, fica fora da garantia.

Atomicidade não encontra sozinha um participante esquecido; ela protege o limite que recebeu.

Uma URL TIP coordenava o encontro

O contexto podia ser propagado por PUSH ou PULL. No PUSH, o superior mandava o subordinado associar a transação. No PULL, a aplicação entregava uma URL TIP e o subordinado usava endereço e referência para se alistar.

A URL deveria ser globalmente única para sempre, mas o método ficava a cargo da implementação. UUID aparecia como possibilidade; a RFC 4122, posterior, não pode ser projetada para trás como formato obrigatório. O próprio TIP não executava a URL: ela viajava no diálogo da aplicação.

Por isso, possuir a referência não provava que o PULL havia funcionado, que a operação era autorizada ou que recursos estavam confirmados. Tratava-se de um ponto de encontro, não de um recibo.

PREPARED criava uma dívida operacional

O TIP normalmente usava TCP, podia negociar TLS e multiplexava transações. Estados como Initial, Idle, Begun, Enlisted, Prepared, Multiplexing, TLS e Error limitavam as próximas mensagens válidas entre gerenciadores. Não descreviam a jornada comercial inteira.

PREPARED significava que o subordinado reteve informação durável suficiente para obedecer à decisão superior mais tarde. Uma falha na preparação não significava automaticamente ABORT. Enquanto o desfecho não fosse recuperado, a transação preparada consumia recursos e mantinha uma obrigação real.

COMMIT também tinha escopo preciso: era a decisão do coordenador sobre o conjunto alistado. COMMITTED relatava o resultado protocolar do subordinado. Entre isso e o comprovante ao cliente existiam a gravação local, a entrega da resposta, a apresentação da aplicação e a observação posterior do negócio.

O resultado podia chegar sem a resposta final

A RFC 2372 reconheceu que um cliente podia não receber o resultado final mesmo quando a transação terminava com sucesso. A aplicação precisava descobrir o desfecho por outro meio, talvez um log específico da implementação. Silêncio não equivalia a aborto, e repetir sem reconciliar podia duplicar uma ação já consumada.

Registros persistentes, RECONNECT e QUERY recuperavam a relação preparada entre gerenciadores após falhas. Preservavam a decisão dentro do sistema de coordenação, não toda a experiência do usuário. A aplicação ainda precisava conciliar a confirmação apresentada e o estado comercial resultante.

Segurança não atravessava a fronteira sozinha

TLS podia ser usado, mas a política era local. A RFC alertava que proteger a aplicação sem proteger o protocolo de confirmação poderia comprometer a própria aplicação. O inverso também valia: uma sessão TIP protegida não autenticava nem autorizava automaticamente a compra.

PULL podia ser abusado para provocar abortos. PUSH podia manter numerosas transações preparadas e esgotar recursos. Reconexões ou decisões forjadas podiam corromper o resultado. Eram riscos da autoridade no canal de coordenação, não evidência de que o TIP fosse o sistema de identidade do negócio.

A cadeia completa separava solicitação, contexto, alistamento, trabalho local, registro PREPARED, decisão, mutação do recurso, resposta, confirmação ao usuário e estado observado. O TIP fortalecia o centro dessa cadeia.

Pela lente da “especificação inicial mínima” de Lu Heng, essa modéstia foi uma virtude: padronizar só o acordo necessário, sem anexar as semânticas da aplicação. A primazia do código em execução exige observar registros duráveis, transições e recuperação. As camadas da realidade impedem que COMMIT, COMMITTED, uma mensagem na tela e o saldo posterior sejam relatados como o mesmo fato.

A RFC 2371 ofereceu um comprovante importante do sistema de coordenação. Nunca o transformou no comprovante integral do negócio.