S2JDBC & Hibernateベンチマークの感想

Hibernateは永続コンテキストを管理することがかかるので、大体S2JDBCの2倍前後処理時間がかかりますね。
永続コンテキストの一番の目的は、透過的な更新ですが、これが本当に有効かどうかは疑問です。一見便利に見えるんだけど、裏で勝手に更新されるので、それに振り回されちゃうケースが多いのではないでしょうか。特に関連とCASCADEが絡むとさらに事情を難しくします。
永続コンテキストとエンティティの状態は表裏一体ですが、エンティティの状態遷移に悩まされた人も多いはず。
結局、永続コンテキストは、ちょっと楽をしようとして、多くの複雑性とパフォーマンスの低下をもたらしていると思います。
S2JDBCは、「トラブリにくくする」というテーマがあるので、永続コンテキストは仕様に含めていません。思わぬSQL文が発行されることはなく、開発者が呼び出したクエリしか実行しません。
永続コンテキストのオーバーヘッドは、検索系なら2倍前後なので、それほど気にならないんですが、更新系は、一桁違ってくるので、大量データの更新には向いていないと思います。
対応策として、少量のデータのときは、Hibernateで、大量のデータ更新は、素のJDBCでという使い分けがでてくると思いますが、どれくらいのデータから素のJDBCに切り替えるだとか、基準が難しいし、プロジェクトが複雑になる気がします。できれば、データ量に関係なく同じフレームワークを適用できることがのぞましいのではないでしょうか。
ちなみに、JPAの標準だと更新されたカラムだけ更新するということはできないはず。Hibernate固有のオプションを使えばできますが、その場合は、たぶん、バッチ更新が効かなくなるので、かえって遅くなるはず。バッチ更新は、すべて同じSQL文を適用しないといけないので、エンティティごとに違うSQL文にはできないのです。