1

ページネーションを行うユースケースがあります。もちろん、ユーザーが移動すると、同じページに再びアクセスします。ページの主キーのセットはすでにあります。

また、同様の検索は、第1レベルと第2レベルのキャッシュにすでにロードされているエンティティの一部にヒットします。

主キーのバッチのクエリを実行すると、Hibernateは、データベースがキャッシュヒットした場合にデータベースを呼び出さないようにするのに十分賢くありません。したがって、最初にプライマリレベルとセカンダリレベルのキャッシュに低レベルのAPIを使用して、これを修正したいと思います。

したがって、たとえば、次の主キーをロードする場合：1、2、3

2がすでに第1レベルのキャッシュにある場合は、1と3でデータベースを呼び出したいだけです。

そのため、session.peek（MyEntity.class、2）のようなAPIを探しています。このAPIでは、peek関数が見つからない場合はnullを返し、第1レベルまたは第2レベルのキャッシュで見つかった場合はエンティティを返します。

存在する場合は、さらに低レベルのAPIからこの関数を作成してもかまいません。

4

1 に答える 1

1

実際、これはすでに Hibernate で実装されており、 query cacheと呼ばれています。仕組みは次のとおりです。

  1. リストの最初のページにアクセスするたびに、Hibernate は最初のページのすべてのエンティティを 2 番目のレベルのキャッシュに入れます (ID -> エンティティ)。

  2. さらに、Hibernate は生の ID をいわゆるクエリキャッシュに入れます。このキャッシュのキーは、クエリ + クエリ パラメーター (どのページといくつのアイテム) です。

  3. 次にユーザーが同じページにアクセスすると、Hibernate は最初にクエリ キャッシュをチェックします。キャッシュにヒットした場合 (同じクエリが同じパラメーターを使用して少し前に実行されている場合)、その時点で返されたレコードの ID が返されます。

  4. 次に、データベースにアクセスする代わりに、二次キャッシュを使用してこれらのレコードを取得します。もちろん、一部のレコードが L2 にない場合、Hibernate は気付かないうちに自動的にフェッチします。

達成したいサウンドを正確に。残念なことに、クエリ キャッシュを調整して効果的に使用することは非常に難しく、設定を誤るとシステム全体のパフォーマンスが低下します。

また、クエリ キャッシュはデフォルトでは有効になっていません。その場合でも、キャッシュするクエリを明示的に定義する必要があります。

于 2012-07-17T13:21:49.230 に答える