要約

  • RFC 2371が共通化したのはトランザクション管理者同士の二相合意であり、注文、認可、参加者登録、利用者への通知は別の仕組みに残された。
  • PREPAREDやCOMMITTEDは強い運用証拠だが、予定した処理がすべて参加したことや、呼び出し側が結果を受け取ったことまでは証明しない。

注文を運ぶ管と、決定を運ぶ管

1998年7月のRFC 2371は、Transaction Internet Protocol（TIP）を簡潔な二相コミットプロトコルとして標準化した。注文や予約の中身はアプリケーションプロトコルで運び、TIPは複数のトランザクション管理者がコミットかアボートかを合意するために使う。仕様はこれを「two-pipe」モデルと呼んだ。

この分離により、TIPは業務ごとのデータ表現を抱え込まずに済んだ。既存システムは固有の会話を続け、管理者だけが小さな共通語を話せばよい。既存の二相コミット方式をすべて置き換える、という主張でもなかった。

一方、分離された二本の管は証拠の限界も示す。COMMITTEDという応答が正しくても、利用者が確認を見たか、送るはずの要求が実際に送られたか、アプリケーションが取引の範囲を正しく選んだかは分からない。一方の管の整合性は、もう一方の欠落を補えない。

境界を決めるのはアプリケーション

仕様の買い物例では、ローカル管理者と複数の遠隔管理者を同じ取引に参加させ、複数の注文をまとめて確定する。しかしTIPが原子的に扱えるのは、登録された参加者だけだ。何を一つの業務単位に含め、いつコミットを始めるかはアプリケーションが決める。

RFC 2372は、この責任をさらに具体化した。二本の通信が分かれている以上、TIPは全アプリケーション要求の順序や完了を必ずしも強制できない。未完了の要求があるままコミットしてはならず、ローカル管理者への登録前に成功を返してもならない。予定された参加者が登録されなければ、その外側の仕事は原子性の対象にならない。

つまり「取引は原子的だった」と「業務設計どおりの全作業が取引に入った」は別の命題である。

TIP URLは合流地点であって証明書ではない

コンテキストの伝播にはPUSHとPULLがあった。PUSHでは上位管理者が下位管理者に関連付けを求める。PULLではアプリケーションがTIP URLを相手へ渡し、下位側がその参照を使って参加する。

TIP URLには管理者の場所と取引参照が入る。全期間を通じた世界的な一意性が求められたが、生成方法は実装に任された。UUIDは候補として触れられただけで、後年のRFC 4122を当時の必須形式として読み込むことはできない。

またTIP自身がそのURLを使って業務を実行するわけではない。参照はアプリケーション側の管で運ばれる。URLを持っていること、PULLが成立したこと、要求が認可されたこと、資源が確定したことは、それぞれ別の記録である。

PREPAREDが作る現実の負債

TIPは通常TCP上で動き、TLSを利用でき、一つの接続で複数取引を多重化できた。Initial、Idle、Begun、Enlisted、Prepared、Multiplexing、TLS、Errorといった状態は、管理者間で次に許される発言を定める。業務全体の状態名ではない。

PREPAREDは特に重い。参加者が上位の最終決定に従えるよう、回復情報を永続化したという約束だからだ。準備の失敗が自動的なABORTを意味するわけでもない。準備済み取引は、結果が確定して回収されるまで資源と運用責任を占有する。

COMMITも限定された言葉である。調整者が登録済み取引に対して出す決定であり、COMMITTEDは下位側のプロトコル応答だ。その先にはローカル資源の更新、応答の配送、画面表示、後日の業務状態がある。

成功したのに返事がない

RFC 2372は、コミットを呼び出したクライアントが最終結果を受け取れなくても、取引自体は成功している場合があると説明した。アプリケーションは実装固有のログなど、別の手段で結果を確認しなければならない。沈黙をアボートと決めつけると、既に実行済みの操作を再試行する危険が生じる。

TIPの永続記録、RECONNECT、QUERYは、障害後に準備済み関係を復元し、結果を問い合わせるための仕組みだった。ただし復元するのは管理者間の判断であって、利用者が確認を見たかという物語ではない。業務側の照合は残る。

セキュリティも二本の管をまたいで自動継承されない

TLSは利用可能だったが、適用はローカル方針に委ねられた。RFCは、アプリケーション通信だけを守ってコミット通信を無防備にすれば、前者の安全性まで損なうと警告した。反対に、TIP接続が保護されていても、購入そのものの本人確認や権限確認を証明するわけではない。

PULLは不正な中止を誘う経路になり得る。PUSHは準備済み状態を大量に残して資源を拘束し得る。偽の再接続や結果指示は取引結果を壊し得る。これらは調整チャネルの権限問題であり、TIPが業務の認証基盤になったことを意味しない。

RFC 2371が強くしたのは、要求、コンテキスト伝播、参加登録、永続的準備、調整者の決定、ローカル確定、応答、利用者への通知、後日の業務状態という長い証拠列の中間部だった。

Lu Hengの「最小初期仕様」という視点では、この狭さこそ価値である。相互運用に必要な合意だけを共通化し、業務語彙と認可を外に残した。「動くコードの優位」は、名前ではなく登録、永続化、実行、回復を確認せよと求める。「現実の層」は、COMMIT、応答、受領表示、残高を同じ事実として扱うなと教える。

TIPのCOMMITは調整システムからの重要な受領証だった。しかし、それは業務完了の受領証ではなかった。