2 フェーズコミットと Logging Last Resource，特許とオープンソース
昨日 JSUG の ML で 2 フェーズコミット (2PC) についていろいろ書いたついでに WebLogic のドキュメントを参照したりしたところ，Logging Last Resource (LLR) という最適化があることを知りました．
2PC の最適化というと Last Resource Commit (LRC) Optimization というのがあり，S2JTA でも Seasar2.2.9 から実装しています．
LLR は LRC の応用で，1 フェーズでコミットするリソースを RDBMS にして，そいつのテーブルをトランザクションログとして使ってしまおうというものらしい．
普通にファイルへ書き込むのと RDBMS への INSERT と，どっちがパフォーマンス的に有利なのか微妙なところもありそうですが，運用環境の中でもっとも頑健なハードウェアを備えていることが多い RDBMS をそのままトランザクションログとして使えるのはなかなか魅力的なアイディアです．
トランザクションログを保存する RDBMS に関しては，ヒューリスティックな決定を避けられるというのもよさげ．
その LLR，いつ頃からあったのかとググってみたら，BEA が特許を取っていたらしい？
そうなのか，それじゃあおいそれと S2JTA で実装するってわけにはいかないのかなぁ．
なんて思ったら，なにげに Sun Java System Application Server (SJSAS) でも実装しているかも？
6492944 Logging Last Resource feature support is required for SpecJ numbersLL
この記述だけでは，これが BEA の LLR と同じものかどうか分からないのだけど，その可能性はありそう．
6492944 ってなぜかバグデータベースに存在しないから詳細が分からないのだ．
ともあれ (JW)，同じものだと仮定して．
SpecJ というのはアプリケーションサーバのベンチマーク (SPECj AppServer) でしょう．
BEA や IBM，Oracle が最高記録を更新とかたまーに見かけるやつ．
そこで必要になったということは，パフォーマンス面でのメリットが大きいということですね．
BEA の特許に抵触しないのかなぁ？
ってこのくらいの規模の企業同士だと，クロスライセンス契約があったりして問題なくても不思議じゃないですね．
でもでも，GlassFish V2 にも含まれている？
6492944 Logging Last Resource feature support is required for SpecJ numbersLL
これは，Sun (？) が他社 (BEA) の特許をオープンソースのコードに含めている可能性があるってことなんだけど，大丈夫なんだろうか？
とりあえず GlassFish (v2-b43) のソースをゲットして軽く眺めてみたけど，該当のコードがどこか分からない．．．
もしかすると，「米IBM、特許500件をオープンソース陣営に無償公開」のように BEA が LLR の特許を使えるようにしてくれているのだろうか？
あるいは，BEA 特許とは別物ということなのだろうか？
そもそも LLR は特許でも何でもないのだろうか？
たぶんないと思うけど，万が一 S2JTA で LLR を実装したくなったときのために，特許とオープンソースの関係とか LLR は本当に特許なのかとか，特許だとして Seasar でも使っていいのかとか，知りたいなぁという業務連絡でした．
P.S.
GlassFish の Java Transaction Service のソースを見ると，元は IBM のコードがベースなのね．
// Copyright (c): 1995-1997 IBM Corp.
//
// The source code for this program is not published or otherwise divested
// of its trade secrets, irrespective of what has been deposited with the
// U.S. Copyright Office.
//
// This software contains confidential and proprietary information of
// IBM Corp.
って入ってるコードがたくさんある．
WebSphere と共通のコードも含まれているのだろうか？
1995-1997 年というと，ちょうど WAS V1.0 のリリース前くらいだなぁ．
P.P.S
帰りの電車の中でつらつら考えていたら，LRC では問題になる 1 フェーズでコミットするリソース (ラストリソース) の障害も LLR では問題にならないことに気がついた．
LRC の場合，ラストリソースがコミット中に障害になった場合，トランザクションマネージャ (TM) は次のどちらなのかを判断することが未来永劫できません．
- コミットが完了する前に障害が発生した．
- コミットが完了した後，その報告を得る前に障害が発生した．
そのため，そのトランザクションをコミットすべきかロールバックすべきかを判断する術がなく，一か八かでコミットするかロールバックするかのどちらかになります (S2JTA はロールバックする)．
元々トランザクションログを取らなくて障害があっても回復を行わない S2JTA では他にもそういう状況は起こりうるので (相対的に) 大きな問題とは考えていませんが，トランザクションログを取る本物の JTA 実装では性能と信頼性のトレードオフを考える必要があります．
ところが LLR の場合，ラストリソースとなる RDBMS にトランザクションログが記録されるので，その RDBMS が復旧した後にログをチェックすればトランザクションがコミットできたのかどうかバッチリ分かります．
素晴らしい．
P.P.P.S
上で LRC の場合ラストリソースのコミット中に障害になると TM は状態を未来永劫判断できないと書いたのは，ラストリソースが XA 非対応のコネクションを使っている場合を想定していたため．
ホンモノの XAConnection/XAResource を使った場合はそのリソースが復旧すればトランザクションの状態を取得できます．
