Summary

  • RFC 2371 standardised a narrow two-phase agreement among transaction managers; application requests, participant registration, business authorisation and the user's receipt travelled through other systems.
  • Its recovery machinery made a prepared transaction durable and queryable, but even a valid COMMIT exchange could not prove that every intended request joined the transaction or that the caller learned the outcome.

Two pipes, one tempting illusion

RFC 2371 arrived in July 1998 as a Standards Track specification for the Transaction Internet Protocol, or TIP. It described a simple two-phase commit exchange among transaction managers. The subject matter of a transaction—the order, booking, transfer or other application work—moved through a different protocol. The document called this a “two-pipe” model.

The split was practical. TIP did not need to standardise every application's message format or business vocabulary. Existing systems could carry their own requests while transaction managers used a small common language to decide whether the participating work should commit or abort. The authors did not present TIP as a universal replacement for existing commit protocols.

But the split also placed a hard limit on the evidence. A transaction manager could truthfully report COMMITTED without knowing whether the customer saw a confirmation page, whether an intended application request was never sent, or whether the application had mistaken its own unit of work. Coordination could be correct within its pipe while the business account was incomplete in the other.

The application drew the border

The RFC's shopping example joined a local transaction manager to remote managers so that several orders could be committed together. The protocol supplied atomic agreement among the enlisted managers. The application decided what counted as the transaction and when it was ready to commit.

That decision contained the most dangerous invisible state. An application might still have a request in flight. A remote service might have done work before registering with its local transaction manager. A participant expected by the business design might never have enlisted. RFC 2372, the companion implementation guide, therefore warned that TIP could not necessarily enforce application-message serialisation in a two-pipe system. The application must not ask for commit while requests were outstanding, and it should not report success before the relevant transaction manager had registered.

The distinction is not pedantic. Atomicity covers the participants inside the declared transaction. It does not discover an omitted participant or repair an incorrectly drawn boundary.

How a transaction found another manager

TIP supported two ways to propagate context. In PUSH, a superior transaction manager contacted a subordinate and told it to associate work with the transaction. In PULL, a subordinate received a TIP URL through an application protocol and used that reference to enlist with the remote manager.

The URL joined an address and a transaction reference. It was meant to be globally unique for all time, although the method for achieving uniqueness remained implementation-specific. The RFC mentioned UUIDs as one possible family of techniques; the later RFC 4122 should not be read backwards as a mandatory TIP format.

Crucially, TIP itself did not “open” the TIP URL. An application carried the reference across its own pipe. The URL was a rendezvous coordinate, not a receipt. Possessing it did not prove that PULL succeeded, that the application request was authorised or that any resource had committed.

A state machine with bounded claims

The protocol ran normally over TCP, could negotiate TLS and could multiplex several transactions over one connection. Its states included Initial, Idle, Begun, Enlisted, Prepared, Multiplexing, TLS and Error. Each state described what the two transaction managers could validly say next; none described the entire business process.

PREPARED was especially important. It meant the subordinate had promised it could later honour the superior's outcome and had retained the recovery information needed to do so. A failed prepare did not silently mean abort. Once prepared, the transaction occupied durable operational space until an outcome was recovered.

COMMIT also had a narrower meaning than its familiar label suggests. It was the coordinator's outcome instruction within the enlisted transaction. A subordinate's COMMITTED response reported its protocol result. Between those records and a customer-visible receipt lay local resource work, connection failure, response delivery and application presentation.

The missing reply after a successful outcome

RFC 2372 made the ambiguity explicit: a client invoking commit might fail to receive the final result even though the transaction completed successfully. The application needed some other way to determine the outcome, perhaps an implementation-specific log. Silence was not equivalent to abort; a dropped response was not evidence that nothing happened.

TIP's recovery design addressed the transaction-manager layer. Persistent records, RECONNECT and QUERY let managers re-establish a prepared relationship and learn an outcome after failure. That was running code preserving a decision, not a general reconstruction of the user's business journey. Recovery could show that a participant committed while leaving the application to reconcile whether a confirmation was delivered or what later state the customer should see.

Security did not cross the seam by magic

The RFC allowed TLS but left its use to local policy. It warned that protecting application communication while leaving the commit protocol exposed could undermine the application's security. The reverse was also true: a protected TIP session did not authenticate or authorise the underlying purchase.

The two propagation models created different pressure points. A hostile PULL could induce an abort. PUSH could consume resources by leaving transactions prepared. Forged reconnection or outcome traffic could corrupt the result if the coordination channel lacked appropriate protection. These risks belonged to protocol authority and resource control; they did not turn TIP into the application's identity system.

The evidence chain RFC 2371 actually gave us

A defensible account separates at least nine records:

  1. the application issued a business request;
  2. transaction context accompanied the right work;
  3. every intended participant enlisted;
  4. each participant completed its application work;
  5. durable prepare records existed;
  6. the coordinator selected an outcome;
  7. local resources applied that outcome;
  8. protocol acknowledgements returned;
  9. the caller received a truthful business acknowledgement and later observed the expected state.

TIP strengthened the middle of that chain. It never claimed to collapse the chain into one line.

A minimum specification that kept its promises small

Read through Lu Heng's principle of minimum initial specification, TIP's restraint was a design asset. It standardised enough for heterogeneous transaction managers to coordinate while leaving application payloads, data representation, business identity and authorisation outside the protocol. That boundary reduced the price of interoperation.

Running-code primacy adds the operational test: a transaction is not made real by its name, URL or architectural diagram. It becomes observable through registration, durable prepare state, outcome exchange, local resource action and recovery. Reality layers add the reporting discipline: a COMMIT token, a COMMITTED response, a client receipt and a later account balance are related, but they are not interchangeable facts.

RFC 2371's historical lesson is therefore more durable than any one transaction product. A protocol can make agreement reliable only inside the boundary it actually controls. The commit line was a valuable receipt from the coordination system. It was not the business receipt.