上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

役に立ったらぽちっとよろしく。 人気ブログランキングへ

JPAの各製品にはセカンドレベルキャッシュを持つ物が多い。もちろん各製品独自の機能で切る事は出来るんだけど。…JPA1.0の仕様書では特にその事について触れていないっぽい。そして一人のおバカが次のような落とし穴にはまった。

EJBコンテナによるトランザクション開始直後にfindを発行したのにクエリが流れていないらしい事をログで確認。しかも、クエリは流れていないのにエンティティはmanaged状態で返ってきてる。トランザクション開始したばかりなのでpersistence contextにはまだ何のエンティティもないはず…なんじゃこりゃぁー!と思う。で、ここで二次キャッシュの存在に賢い人は気づくはず…が、あるバカは仕様書をしらみ潰しに調べ、拡張永続コンテキスト(TransactionType.EXTENDED)がしらんまに適用されたのか、と勘違いする。で、まる一日格闘した後、clearメソッドを最初に発行してもまだキャッシュされている事に気づき、ようやくpersistence context以外にキャッシュしてる黒幕がいると悟ったバカでした。

で、どうやらこのバカは性格まで悪いらしくJPAの仕様の書き方とそれを実装する各製品にケチをつけだした…。以下その言い分…。

  • やい!JPA!!二次キャッシュに気づけんバカによる操作は"Out of specification"だと思ってるんだろう!でもあんたに従うとDBと正確に同期を取る場合、select系Queryの後に一件毎にrefleshを呼ぶはめになるだろぅが!どれだけ無駄なクエリが流れると思ってんだ!バカって言う奴が馬鹿!
  • やい!Toplink!!二次キャッシュはデフォルト切っとけ!最初にレーシングカーに乗せるな!バカには遅くてもいいから安全なのを渡せ!ていうかお前なんか最初の交差点でスリップして死んじまえ!

…なんか最近変なバグまがいの仕様が増えて超鬱なバカでした…はぁ…。(ちなみにToplinkは主キーが指定されているクエリだけ二次キャッシュを使うみたい…。)

で、それはいいとして、まだEarly Draftの段階だけどJPA2.0からは二次キャッシュがちゃんと明文化されるとさ…で、Toplink EssentialはEclipse linkになるってさ…。ふぁっふぁっふぁいとぉ~っ。

スポンサーサイト

役に立ったらぽちっとよろしく。 人気ブログランキングへ

コメント
この記事へのコメント
コメントを投稿する

トラックバック
この記事のトラックバックURL
この記事へのトラックバック
Copyright © ふらふら技術者の日記 All Rights Reserved.
Powered by FC2 Blog
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。