問題タブ [ehcache-3]

アプリケーションで EhCache を分散キャッシュとして使用しようとしています。EhCache インスタンスはサーバーに組み込まれており、terracota クラスターを使用しました。

すべてのサーバー (および ehcache) インスタンスは、この tc に正常に接続します。各キャッシュへの挿入、更新、および取得に成功しました。ただし、キャッシュを反復処理することはできません。

キャッシュを間違った方法で構成した可能性がありますが、反復子メソッドはまだ実装されていないようです (org.ehcache.clustered.client.internal.store.ClusteredStore 内):

キャッシュ構成は次のようになります。

キーリストを取得しても、他の方法は見つかりませんでした。

では、キャッシュの設定を間違えたのでしょうか? それとも、EhCache 分散モードがこの方法と完全に互換性がないということですか (そのため、EhCache は使用しません)。

EhcacheWeb アプリケーション内の高価なサービス呼び出しの結果をキャッシュするために使用しています。

JVM の再起動後もキャッシュを保持したい。

と を使用して 2 層の ehcache を構成しましheapたdisk。PersistentCacheManager.close()残念ながら、Ehcacheは呼び出されたときにのみキャッシュをディスクに保存します。

永続性を適切に機能させるにはどうすればよいですか? 定期的にキャッシュを閉じて再度開く必要がありますか? これについては、ehcache以外のものを検討する必要がありますか?

リモート サービスのサービス コンポーネントを提供する Spring ライブラリを作成しているとします。サービス コンポーネントは応答データを内部的にキャッシュする必要があり、これには Spring キャッシュが非常に適しています。また、キャッシュをデフォルトのもの (タイムアウト、最大サイズなど) よりも少し高度にする必要があると想像してください。そのため、ライブラリはそれを作成するためのキャッシュ マネージャーを提供します。ただし、サードパーティのキャッシュ マネージャーが、ライブラリが含まれるプロジェクトで使用されるすべてのキャッシュを突然担当することは望ましくありません (プロジェクトには独自のキャッシュがある場合があります)。

私が観察している動作は、プロジェクトが単純な application.properties を使用して構成されたキャッシュを使用している場合 (ehcache としましょう - 以下の例を参照)、構成方法に関係なく、コンポーネントによって提供されるキャッシュマネージャーが呼び出されてすべてのキャッシュを作成することです。コード。これは、プロジェクトが独自のキャッシュ マネージャーを提供していないために発生していますか?

プロジェクトが関与せずに、図書館が提供するサービスでこのようなキャッシングを行うことはできませんか? ライブラリがプロジェクトのキャッシュに干渉することなくキャッシュを提供できることは、ユースケースにとって非常に重要です。

サンプル サービス キャッシュ構成:

サンプル プロジェクト application.properties:

サンプル プロジェクト ehcache3.xml:

「サービス データ」キャッシュと「コンテンツ」キャッシュの両方のロギング呼び出しが表示されます。サービス キャッシュ構成は、それ自体のサービス データ キャッシュのみを考慮します。プロジェクトが @Primary を使用して別のキャッシュ マネージャーを宣言しなくても、このキャッシュ専用のキャッシュ マネージャーを提供することはできませんか (うまくいくと思いますが、まだ試していません)。

助けてくれてありがとう！