久しぶりにEJB2.1仕様書を開く。

Weblogic6.1からWeblogic8.1SP2に以降するにあたり、一部のベンダーさんのアプリケーションでEJBの動きがかわった、という問題が発生している。HPさん経由でBEAのエンジニアさんが分析に六本木に来ることになった。この日に備えて印刷しておいたEJB2.1仕様書が、よもや役立つとは。
EJBといってもエンティティビーンのほうである。しかも、ビーン管理永続化(BMP)。これはWeblogic6.0で、まだWeblogicのEJBコンテナがダメダメだったころから使い続けている自社製フレームワークによって自動生成されるEJBであり、いろいろパフォーマンスが出ないとか古いアーキテクチャのままだとかといった問題を除けば実績は３年近くある。これが、WLS8.1で特定のアプリだけ動きが違うというのも不可思議だ。なにかコンテナの動きが変わって、微妙なハマリ具合なのだろうとは予想していたが、よもやejbStoreの挙動そのものが変わっていたとはさすがに驚いた。
従来、Weblogic8.1SP1までは、トランザクションを参加しているエンティティビーンがデータベースにキャッシュを書き戻すタイミングはコンテナが自動的に行うものはコミット時だけであった。パッシベートやアクティベートはトランザクション中には決して発生しない。ところが、WLS8.1になると、find系メソッドを呼び出すとejbStoreが動作してデータベースに書き込むようになったのだ。しかし、この改修はむしろバグフィックスなのだ。これはキャッシュされているレコードの情報をデータベースに反映させなければ検索時に正しい結果が取れないから、本来は、findするまえにはejbStoreによってキャッシュをフラッシュしなければならないとEJB2.1仕様書にキッチリと書かれている。WLS8.1SP1までは、これをサボッていたというわけだ。
ところが、問題となっているアプリではコミットするまでデータベースに反映されない、ということを期待して、データベースにアクセスするような実装になっていたのだ。もちろん、BMPは、いつでもデータベースに書き込めるので、いままでejbStoreが動いていなかったのは「たまたま」であるから、今回のバグフィックスはもとより、いつかは遭遇する潜在的な危険なコード、すなわち偶発的プログラミングをやってしまっていたわけで、アプリケーションがちょっと不味いことは確かなのだが…。
きちんとEJB仕様書を読んでいれば、すぐにわかったのかもしれないが、英文650ページの仕様書をすべて把握し、しかもWLS6.1が、これに準拠していない箇所がどれだけあるかなど、これをトレースするのは事実上不可能ではないのか。
うーん、久しぶりにディープな問題を見せられてしまった。