どちらを使用するかをどのように決定CacheConcurrencyStrategy
しますか?
NonstrictReadWriteCache
、ReadOnlyCache
、ReadWriteCache
、TransactionalCache
.
https://www.hibernate.org/hib_docs/v3/api/org/hibernate/cache/CacheConcurrencyStrategy.htmlを読みましたが、十分に詳しく説明していません。
どちらを使用するかをどのように決定CacheConcurrencyStrategy
しますか?
NonstrictReadWriteCache
、ReadOnlyCache
、ReadWriteCache
、TransactionalCache
.https://www.hibernate.org/hib_docs/v3/api/org/hibernate/cache/CacheConcurrencyStrategy.htmlを読みましたが、十分に詳しく説明していません。
Hibernateのドキュメントは、それらを定義するのに非常に優れています。
19.2.2。戦略:読み取り専用
アプリケーションが永続クラスのインスタンスを読み取る必要があるが変更する必要がない場合は、読み取り専用キャッシュを使用できます。これは、最も単純で最適なパフォーマンス戦略です。クラスターでの使用にも安全です。
19.2.3。戦略:読み取り/書き込み
アプリケーションがデータを更新する必要がある場合は、読み取り/書き込みキャッシュが適切な場合があります。シリアル化可能なトランザクション分離レベルが必要な場合は、このキャッシュ戦略を使用しないでください。キャッシュがJTA環境で使用される場合は、プロパティ
hibernate.transaction.manager_lookup_class
を指定し、JTAを取得するための戦略に名前を付ける必要がありますTransactionManager
。Session.close()
他の環境では、またはSession.disconnect()
が呼び出されたときにトランザクションが完了していることを確認する必要があります 。クラスタでこの戦略を使用する場合は、基盤となるキャッシュ実装がロックをサポートしていることを確認する必要があります。組み込みのキャッシュプロバイダーはロックをサポートしていません。19.2.4。戦略:非厳密な読み取り/書き込み
アプリケーションがデータを更新する必要があるのがたまにしかなく(つまり、2つのトランザクションが同じアイテムを同時に更新しようとする可能性が非常に低い場合)、厳密なトランザクション分離が必要ない場合は、非厳密な読み取り/書き込みキャッシュが適切な場合があります。キャッシュがJTA環境で使用される場合は、を指定する必要があります
hibernate.transaction.manager_lookup_class
。Session.close()
他の環境では、またはSession.disconnect()
が呼び出されたときにトランザクションが完了していることを確認する必要があります。19.2.5。戦略:トランザクション
トランザクションキャッシュ戦略は、JBossTreeCacheなどの完全なトランザクションキャッシュプロバイダーのサポートを提供します。このようなキャッシュはJTA環境でのみ使用でき、を指定する必要があります
hibernate.transaction.manager_lookup_class
。
言い換えると:
読み取り専用:頻繁に読み取られるが更新されないデータ(国などの参照データ)に役立ちます。簡単です。それはすべての中で最高のパフォーマンスを持っています(明らかに)。
読み取り/書き込み:データを更新する必要がある場合に望ましい。ただし、 SERIALIZABLE分離レベルは提供されないため、ファントム読み取りが発生する可能性があります(トランザクションの終了時に、開始時に存在しなかったものが表示される場合があります)。読み取り専用よりもオーバーヘッドが大きくなります。
非厳密な読み取り/書き込み:または、2つの別々のトランザクションスレッドが同じオブジェクトを更新する可能性が低い場合は、非厳密な読み取り/書き込み戦略を使用できます。読み取り/書き込みよりもオーバーヘッドが少なくなります。これは、めったに更新されないデータに役立ちます。
トランザクション:完全にトランザクションのキャッシュが必要な場合。JTA環境でのみ適しています。
したがって、適切な戦略を選択するかどうかは、データが更新されているかどうか、更新の頻度、および必要な分離レベルによって異なります。キャッシュに入れたいデータについてこれらの質問に答える方法がわからない場合は、DBAにサポートを依頼してください。
READ_ONLY:変更されないエンティティにのみ使用されます (そのようなエンティティを更新しようとすると例外がスローされます)。非常にシンプルで高性能です。変更されない静的参照データに非常に適しています。
NONSTRICT_READ_WRITE:影響を受けるデータを変更したトランザクションがコミットされた後、キャッシュが更新されます。したがって、強い整合性は保証されず、古いデータがキャッシュから取得される可能性がある短い時間枠があります。この種の戦略は、結果整合性を許容できるユース ケースに適しています。
READ_WRITE:この戦略は、「ソフト」ロックを使用することで実現する強力な一貫性を保証します。キャッシュされたエンティティが更新されると、そのエンティティのキャッシュにもソフト ロックが格納され、トランザクションがコミットされた後に解放されます。ソフトロックされたエントリにアクセスするすべての同時トランザクションは、対応するデータをデータベースから直接フェッチします。
TRANSACTIONAL:キャッシュの変更は分散 XA トランザクションで行われます。キャッシュされたエンティティの変更は、同じ XA トランザクション内のデータベースとキャッシュの両方でコミットまたはロールバックされます。
トランザクション-更新のまれなケースで、同時トランザクションで古いデータを防ぐことが重要な読み取りがほとんどのデータにこの戦略を使用します。
読み取り-書き込み-更新のまれなケースで、同時トランザクションで古いデータを防ぐことが重要な場合は、読み取りがほとんどのデータにこの戦略を再度使用します。
Nonstrict-read-write - この戦略は、キャッシュとデータベース間の一貫性を保証しません。データがほとんど変更されず、古いデータのわずかな可能性が重大な懸念事項ではない場合は、この戦略を使用します。
読み取り専用-変更されることのないデータに適した同時実行戦略。参照データとしてのみ使用してください。
これで疑問が解消されることを願っています!