一貫性のある状態でJBossの下でHibernateを使用してEntityManagerのキャッシュを維持する方法は？

Question

JBossでHibernateを実行していて、この問題が発生しています。

セッションBeanがEntityManagerを使用してエンティティを検索すると、EntityManagerのキャッシュにすでに存在し、その状態がすでに古くなっている可能性があります。コードがそのようなエンティティを使用して意思決定を行う場合、バグを引き起こすような誤った決定をする可能性があります。

ここでは例を示します。

HTTPリクエスト1.セッションBeanは、エンティティのインスタンスとフィールドとの格納を作成「」永続化エンティティは、セッションBeanがルックアップID = 4

HTTPリクエスト2を取得1.値に設定しますID = 4のエンティティで、フィールド "A"を値2に設定して保存します。

HTTPリクエスト3.セッションBeanはID = 4のエンティティをルックアップし、フィールド「A」をチェックします。値が1の場合は1つの処理を行い、2の場合は別の処理を行います。

要求3のEMが要求1のEMと同じ場合、望ましくない動作が発生します。私はこれを試して、およそ得た。 10％の失敗のケース。

ですから、これを避けるにはどうすればよいですか？エンティティが最新であることを保証する必要があるたびに、em.refresh（）またはem.clear（）を呼び出すと、リソースが無駄になります。

Answer 1

アルテム、

これは、私はあなたが（私を含む）の前に与えられてきた答えは、あなたが望んでいたものではないかもしれないことを理解しながら

:-)ご質問の中でrecurringthemeのようです

• エンティティマネージャは、Hibernateセッションにマップされており、通常は短命である必要があります。 Hereは、Hibernateセッションに関連する作業単位、トランザクション、およびスコープの良い説明です。これまで見たことがないかどうかを見てください。
• が一貫してのEntity Managerを保持している場合は、その戦略の変更を真剣に検討する必要があります。 refresh()メソッドを使用するよりも、長いトランザクションを実際に必要とするいくつかの場所でそれをやっているのであれば、間違いなくすべての悪のうちの小さいものがあります。クラスタ化された実装を有するsecond level cache異なり
• は、セッション・レベルのキャッシュは、Hibernateまたはアプリケーションレベルのロックによって提供optimistic lockingを介して処理される同じエンティティに設計と同時更新によってdiferentセッション（エンティティ・マネージャ）間で同期されていません。
• 理論上（ORMアクセスが十分に分離されている場合）、さまざまなエンティティ・マネージャが保持するエンティティの独自のキャッシュ（必要に応じてクラスタ化可能）を維持できます。キャッシュを同期させておくために、それぞれに適切なevent listenersを登録する必要があります。私は、このアプローチに対して強くアドバイスします。実装するのはむしろバグが発生しやすいだけでなく、これでHibernateのパラダイムに逆行するでしょう。