私が取り組んでいるプロジェクトでは、Hibernate をプロバイダーとして Spring 2.5 と JPA を使用しています。
私の DAO クラスは JpaDaoSupport を拡張しているので、getJpaTemplate() メソッドを使用して JpaTemplate を取得します。
バックエンド データベースは、自分のアプリケーションまたはサードパーティ アプリケーションによって変更される可能性があります。
サードパーティのアプリケーションがデータベースを変更した場合 (主に構成データの変更)、アプリケーションのユーザーに、すべての JPA セッションを無効にして新しいデータをリロードする方法を提供する必要があります (つまり、バックグラウンドで休止状態のセッションをすべて無効にします)。これは、アプリケーションのすべての同時ユーザーが「見る」必要があります。
これどうやってするの？
キャッシュには次の 2 つのレベルがあります。
第 1 レベルは EntityManager 自身のキャッシュです。
refresh1 つのエンティティでデータベースからリロードされるか、エンティティ マネージャ自体で行うことができます。clearこの場合、すべてのエンティティがキャッシュから削除されます。JPAでは、キャッシュから特定のエンティティを 1 つだけ削除する方法はありません。使用する実装に応じて、これを行うことができます (例: Hibernate のevictメソッド)。
第 2 レベルのキャッシュはグローバル キャッシュです。
JPA 1.0 は、2 次キャッシュをサポートしていませんでした。その場合、基になる特定の実装に依存するか、無効にする必要があります。JPA 2.0 では、@Cacheアノテーションとキャッシュ API を使用してこの問題に対処します。Hibernate 固有の API を使用して、第 2 レベルのキャッシュをクリアできますSessionFactory.evict(...)。
キャッシュに関する高度な問題は次のとおりです。
クエリ キャッシュ
特定のクエリの結果をキャッシュできます。これも JPA 1.0 ではサポートされていませんが、ほとんどの実装には、どのクエリをどのようにキャッシュするかを指定する方法があります。
クラスタリング
次に、クラスター内のノード間でキャッシュを同期するという面倒な問題も発生します。この場合、これは主に、JBoss キャッシュなど、使用されるキャッシング テクノロジーに依存します。
あなたの質問は依然として一般的であり、答えはあなたが正確に何をしているかによって異なります。
多くの更新が休止状態を経ずに行われるシステムに取り組み、最終的に第 2 レベルのキャッシュを無効にしました。
ただし、開いているすべてのセッションを追跡し、必要に応じて、開いているすべてのセッションのすべての第 1 レベルのキャッシュと第 2 レベルのキャッシュを削除することもできます。自分で同期を管理する必要がありますが、それは可能だと思います。
アーキテクチャの観点からは、他のアプリケーションにすべてのビジネス ロジックをバイパスさせ、永続データを変更させることはあまり良い考えではありません。それはあなたのアプリケーションの足元の地面を多くの方法で不安定にします:)
メッセージ処理やバッチ処理など、より洗練された方法でこの他のシステムと統合するのは良い考えではないでしょうか。Spring は、その両方を強力にサポートします。