問題タブ [second-level-cache]

Given example from Hibernate docs and modifying it so that root level entity (Customer) is read-only while one of its collections (tickets) is read-write:

Would collection of tickets get refreshed when accessing customer from cache?

この質問は、私が思う写真で最もよく説明されています。誰かが私を助けてくれることを願っています。ありがとう

同じNHibernateという名前のクエリを同じパラメーターで2回（毎回異なるセッション）実行する単純な単体テストがあります。これは単純なintパラメーターであり、私のクエリは名前付きクエリであるため、これら2つの呼び出しは同一であり、結果をキャッシュする必要があると想定しています。

実際、ログで結果がキャッシュされていることがわかりますが、キーは異なります。したがって、2番目のクエリ結果がキャッシュに見つかりません。

これが私のログからの抜粋です（キーがどのように異なるかに注意してください）：

（最初のクエリ）

DEBUG NHibernate.Caches.SysCache2.SysCacheRegion [（null）] <（null）>-新しいデータの追加：key = [snipped] ...パラメーター：['809']; 名前付きパラメーター：{} @ 743460424＆value = System.Collections.Generic.List`1 [System.Object]

（2番目のクエリ）

DEBUG NHibernate.Caches.SysCache2.SysCacheRegion [（null）] <（null）>-新しいデータの追加：key = [snipped] ...パラメーター：['809']; 名前付きパラメーター：{} @ 704749285＆value = System.Collections.Generic.List`1 [System.Object]

クエリキャッシュを使用するようにNHibernateを設定しました。そして、これらのクエリをcacheable=trueに設定しています。他にどこを見ればいいのかわからない。誰か提案がありますか？

ありがとう
-マイク

2つのJavaWebアプリは両方とも読み取り/書き込みであり、3つのスタンドアロンJava読み取り/書き込みアプリケーション（1つは電子メールで質問をロードし、1つはxmlフィードを処理し、もう1つはサブスクライバーに電子メールを送信します）はすべて休止状態を使用し、共通のコードベースを共有します。

最近遭遇した問題は、電子メールを介してロードされた質問が、Webアプリの1つで作成された質問を上書きすることがあるということです。これらは別々の質問であり、別々のIDが必要であることに注意してください。当初、これはキャッシュの問題であると考えていました。2番目のレベルのキャッシュをオフにしてみましたが、違いはありません。

質問：

MySQLを使用しています。

セッションを明示的に開始および終了するのではなく、休止状態でを介してセッションを管理しますUtil.getSessionFactory().getCurrentSession()。

この段階では、クラスター化された第2レベルのキャッシュをセットアップするのではなく、複雑さの別のレイヤーが作成され、アプリ全体から得られるパフォーマンスのレベルに満足しています。

では、Webアプリでopen-session-in-viewパターンを実装し、スタンドアロンアプリでセッションを手動で管理することは、これを修正するように聞こえますか？

または他の提案/アイデアをお願いしますか？

hibernate の二次キャッシュとは何ですか?

私のgrailsアプリケーションでは、すべてのリージョンからの 2 次キャッシュの現在のすべてのエントリを表示したいと考えています。

私のコードは次のとおりです：

ただし、リージョン名がそうでない 限り、すべてが正常に機能しますorg.hibernate.cache.StandardQueryCache(リージョンはQuery Cacheに使用されます)。その場合、例外がスローされます。

グーグルで調べてみたところ、地域とに関連付けられたキャッシュされたクエリ結果セットのエントリのリストを表示する方法についての手がかりが見つかりませんでした。StandardQueryCacheUpdateTimestampsCache

この問題の解決策を教えてください。

私の同僚と私は、2 番目のレベルのキャッシュにキャッシュされたコレクションが古いデータを返す可能性がある場合 (if?) について議論してきました (私たちは ehcache と hibernate 3.2.4 を使用しています)。

シナリオは次のとおりです。

• 親オブジェクト P はキャッシュされ、エンティティです。
• 親には、キャッシュされて怠惰な子のコレクション (バッグ) があります。
• 子オブジェクト C はキャッシュされ、エンティティです。
• これらすべてのキャッシュ同時実行戦略として、Nonstrict read-write を使用しています。
• 私たちのセッション ファクトリはプロセス スコープであり、関与する JVM は 1 つだけです。
• 上記のすべてのキャッシュのキャッシュ領域は、すべての子と親のすべてのインスタンスをメモリ内に簡単に保持するのに十分な大きさであると想定します。

時間 T1: すべての C1...CN が読み込まれるように、session.load(p) を実行し、子コレクションを反復処理することによって、親 P と子 C1...CN を読み込みます。

時間 T2: 別のセッションが C1 をロードし、C1 を更新してデータの一部を変更します。

P.getChildren().get(0) を呼び出すと、C1 の古いバージョン (時間 T1 にロードされた C1 のバージョン) が返されるのはどのような状況ですか?

私は2つあると考えています:

1. T1 の操作と同じ休止状態セッションにいる場合 (この場合、セッション キャッシュ バージョンが返されます)
2. 非厳密な読み取り/書き込みでは、T2 での更新とロードがほぼ同時に発生し、ロードが競合に勝ち、キャッシュから古いオブジェクトを取得するという競合状態が発生する可能性があります。（その場合、読み書きに変更でき、問題ありません）

最新のデータベースは、キャッシュのサポートを提供します。ほとんどの ORM フレームワークは、取得したデータもキャッシュします。なぜこの重複が必要なのですか？

私たちのJavaアプリケーションには、データベース（SQL ServerまたはMySQL）にマップされた約100のクラスがあります。ORMとしてHibernateを使用しています（XMLマッピングファイルを使用）。

FOREIGN KEYデータベーススキーマで制約を指定します。ほとんどのFOREIGN KEY制約では、も指定されていますON DELETE CASCADE。

最近、パフォーマンスの問題を軽減するために、Hibernateの第2レベルのキャッシュ（人気のあるエンティティとコレクション用）の有効化を開始しました。

2次キャッシュを有効にしてから、パフォーマンスが向上しました。ただし、ObjectNotFoundExceptionsも発生し始めています。

データベースがHibernateの下のテーブル行を削除しているため、ObjectNotFoundExceptionsが発生しているようです。たとえば、ParentHibernateを使用してを削除すると、データベーススキーマはON DELETE CASCADEすべてのChildエンティティに適用されます。これは明らかにHibernatesの知識がなくても発生するため、第2レベルのキャッシュを更新する（および削除されChildたエンティティを削除する）機会はありません。

この問題の解決策はON DELETE CASCADE、データベーススキーマから削除することです（ただし、FOREIGN KEYsは保持します）。代わりに、Child通常の削除SQLを使用して依存関係を削除するようにHibernateを構成する必要があります。これにより、Hibernateは第2レベルのキャッシュも更新します。いくつかの限られたテストでは、このアプローチが機能しているように見えることが示されています。

これについてコミュニティからのフィードバックをもらいたかったのです。私たちの問題に対する代替の（より良い？）解決策はありますか？他の人はこの状況にどのように対処しますか？ON DELETE CASCADE一般に、 Hibernateを使用してデータベーススキーマで使用する場合に考慮すべきトレードオフは何ですか？

ありがとう。

第 2 レベルのキャッシュに MySQL、Hibernate (3.5.1-Final)、および EHcache(1.2.3) を使用する Java アプリケーションがあります。

hibernate.properties 分離レベルは Read-committed 分離 = 2 です。

多数の同時トランザクションの下で、ロード時に特定のコレクション (DB 関連付け) が ObjectNotFoundException をスローし、第 2 レベルのキャッシュがそのコレクションの古いコピーを返しているように見えるという問題が発生しています。

このコレクションにアクセスする (読み取りのみ) さまざまな種類のトランザクションがあり、そこから項目を追加/削除するトランザクションは 2 つだけです。

この問題は、単一のトランザクション ロードまたは中程度のトランザクション ロード (10 ～ 20 の同時接続) では見られません。

たとえば、 Character エンティティがあります。

エンティティが含まれているコレクションからエンティティを削除し、session.delete() を呼び出すことで、エンティティを削除するときにオブジェクト グラフを適切に維持しています。

セット項目を変更してみました。CacheConcurrencyStrategy から:

に

運がない。

データベース ロックは使用せず、代わりに楽観的同時実行制御を使用して、競合するトランザクションをキャッチして再試行します。

この時点で確認できる解決策は次の 2 つだけです。

1. ObjectNotFoundExceptionをキャッチして、コレクションをインテリジェントに削除しようとします (ただし、例外には十分なコンテキストがないようです)。

2. アイテム コレクションで@NotFound(action=NotFoundAction.IGNORE)アノテーションを使用します。これにより、ObjectNotFoundException は無視され、スローされません (ただし、これが第 2 レベルのキャッシュでどのように機能し、適切なデータが参照されているかについては懸念があります)。 .

@NotFound(action=NotFoundAction.EVICT_2ND_LEVEL_CACHE_RELOAD) があれば、そのオブジェクトをキャッシュから追い出し、コレクションをリロードしようとします。

FetchyType を LAZY から EAGER に変更することもできますが、問題を理解し、トランザクションのデータが高い並行性の下で一貫していることを提供する最適なソリューションを選択したいと考えています。