The Two-phase commit implementation could be XA-compliant ?

PGの今回の2PC実装について引き続き少し調べてみたが、中途半端で危険というのが印象だ。最近の（５月位からの）議論にはXAインターフェイスのことはほとんど出てきていないようだし、わずかに出た質問（もっともな質問だと思うが）も無視されてしまったようだ。生の２PCのみを議論して、標準の中での位置付けを意識しようとしないのは全く理解しがたい。中途半端な仕様に則って周囲の実装を始めてしまうほど危険なことはない。触らぬ２PCにたたりなしといったところか。
XAインターフェイスについて言えば、初めてその仕様を見た時何と難解なのだろうと思った。残念ながら現在でもわかっているとは言いがたい。いまだにわからない最たるものは、制御スレッド（thread of control）の概念。ちゃんとした定義があるとは言いがたいし、正直誰もが共通の理解に達するものには思えないがどうだろうか。その曖昧模糊とした制御スレッドはxa_start()によってあるグローバルトランザクションの１ブランチにassociateされ、xa_end()によってdissociateされる。この肝心な部分が今回の実装では全く？存在しないようなのだが、これでXA-compliantになりうるのだろうか？　また、PREPARE TRANSACTIONコマンドによって初めてグローバルトランザクションのブランチに参加（したことを意識）することになるのだが、これまたXA対応にはそぐわないと思う。先に説明したとおり、XAでは各制御スレッドは特定のトランザクションブランチとはxa_start()〜xa_end()の期間以外関連をもっていない。従ってxa_end()後、その制御スレッドはPREPARE要求など待たずに、自由に全く別ののトランザクションブランチに参加できるし、他の制御スレッドがxa_end()後空き状態になった当該のトランザクションブランチに参加することも自由である。つまり複数の制御スレッドが協力して一つのトランザクションブランチを作り上げることができるわけで、分散トランザクションとはロケーションの分散のみでなく機能の分散みたいな意味まで含んでいることになる。なのでxa_preprare()やxa_commit()は任意の制御スレッドから発行することが出来ないと困るはずであり、実際そいういう仕様になっている。xa_prepare()はどこからとんでくるかわからないけれどグローバルトランザクションIDが指定されるので何をしたらいいかはわかっているでしょうというのがXAの要求する所であり、PREPAREの段階ではじめてグロバールトランザクションを意識することになる今回のPG方式では対処のしようがないだろう。XAとは水と油の方式としか思えないのだが。
残念ながら、どうすればXA-compliancyを実現できるのかは私にもわからないし、一足飛びに実現するのは無理な感じがするのも事実である。ただ問題にしたいのはその方向性みたいなものである。一つは、新しいコマンドを追加したり、FE/BEプロトコルを拡張したりという通常のFE/BE間の会話の延長というやり方で、将来本当にXA-compliancyに結びつくのかということ。もう一つはアルファ版ともいえないような実装の細部をカプセル化しようという姿勢が見えないことである。誰が見ても第一歩にしか過ぎないものを生のまんま公開して、自分の責任で自由にお使いくださいと言えるのは、無責任でいられてオープンソースのとってもよい所ではあるのだが。