Seasar2.4.33 リリース

Tech Seasar

しました．


■変更点

2.4.32 からの変更点は次のとおりです．

  • Bug
    • [CONTAINER-299] - [S2JDBC] SimpleWhere や Operations の starts()/ends()/contains() で，Oracle ではワイルドカードになる全角の '％' や '＿' がエスケープされない問題を修正しました．[Seasar-user:16239]
    • [CONTAINER-300] - [S2BeanUtils] CharSequence型指定時にexcludesメソッドが利かない不具合を修正しました。
    • [CONTAINER-302] - [JPA] Jar ファイル内の永続ユニットを扱うと FileNotFoundException が発生する問題を修正しました．[Seasar-user:16276]
    • [CONTAINER-312] - [S2JDBC]ストアドでOUTパラメータを使わずに結果セットを戻せるRDBMSにおいて、ストアドの最初に更新処理を行うと結果セットが取得できない不具合を修正しました。
    • [CONTAINER-315] - [S2JDBC] byte/Byte 型プロパティのマッピングが漏れていた問題を修正しました．[Seasar-user:16383]
    • [CONTAINER-318] - [S2DBCP] XADataSource のユーザ名を指定しなかった場合にプロパティが反映されない問題を修正しました．
  • Improvement
    • [CONTAINER-319] - [S2JDBC] SimpleWhere や Operations で IN や NOT IN の条件に配列だけでなく Collection を渡せるようにしました．


■移行の注意点


■ダウンロードはこちらからどうぞ．


■Maven2からのご利用はこちらを参照ください．

S2JDBC-Gen 0.9.4 リリース

Tech Seasar

しました．


■変更点

0.9.3 からの変更点は次のとおりです．

  • Bug
    • [CONTAINER-305] - Gen-Ddlで識別子の自動生成用テーブルのDDLを生成する場合にカラムのデータ型が正しくないという不具合に対処しました。
    • [CONTAINER-309] - MS SQL Server用の方言（MssqlGenDialect）がGenDialectRegistryに登録されていない不具合に対処しました。
    • [CONTAINER-311] - Gen-EntityでMS SQL Serverのidentityカラムのデータ型が不適切なJavaの型にマッピングされる問題に対処しました。
    • [CONTAINER-314] - Oracleを使用している場合に、Gen-EntityでJDBCのメタデータから日本語テーブルの一意キーの情報を取得できない不具合に対処しました。
    • [CONTAINER-316] - MigrateやLoad-DataのCSVファイルロード処理で、カンマの直後に改行コード（CR）が続くと値（null）を認識しない場合がある問題に対処しました。
    • [CONTAINER-317] - PostgreSQLを使用している場合に、Gen-EntityでOID型に対応するJavaクラスがbyte[].classにならない問題に対応しました。
    • [CONTAINER-320] - Gen-EntityでshowColumnDefinition属性にtrueを指定した場合に、自動生成される主キーカラムにデフォルト値の定義が出力されることがある問題に対処しました。
  • Improvement
    • [CONTAINER-298] - Gen-Serviceで、ServiceクラスのjdbcManagerプロパティのsetterメソッドに@TransactionAttribute(TransactionAttributeType.NEVER)を付与するようにしました。
    • [CONTAINER-303] - Migrateタスクでバージョン番号を明示的に指定することなく1つ前のバージョンに戻れるようにしました。
    • [CONTAINER-308] - Gen-EntityTest（旧Gen-Test）が生成するテストコードで名前クラスを利用するようにしました。
    • [CONTAINER-310] - データベースのメタデータから想定外の型名が返された場合はJDBCのSQL型を利用してJavaの型へ変換するようにしました。
    • [CONTAINER-313] - Load-Dataで、ロード前に既存のデータを削除できるようにしました。
  • New Feature
    • [CONTAINER-252] - SQLファイルのテストコードを生成するGen-SqlFileTestタスクを用意しました。
    • [CONTAINER-265] - Gen-Ddlで、エンティティに対するリファクタリング内容をコメントとして入力できるようにしました。
    • [CONTAINER-278] - サービスクラスのテストコードを出力するGen-ServiceTestタスクを用意しました。
    • [CONTAINER-296] - Gen-Ddlで、エンティティやエンティティのプロパティに対するコメントをDDLに反映できるようにしました。
    • [CONTAINER-297] - Gen-Entityで、テーブルやカラムに対するコメントをエンティティのJavaコードに反映できるようにしました。
    • [CONTAINER-301] - テストコードを生成するタスクで、S2Unitを使うかS2JUnit4を使うかを選択できるようにしました。
    • [CONTAINER-304] - Gen-Ddlで外部キーのDDL生成を抑制できるようにしました。


■移行の注意点


■ダウンロードはこちらからどうぞ．


■Maven2からのご利用はこちらを参照ください．

2 フェーズコミットと Logging Last Resource，特許とオープンソース

Tech

昨日 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 を使った場合はそのリソースが復旧すればトランザクションの状態を取得できます．