3

spring と ehcache を統合する必要があり、blockingCacheパターンで実装しようとしています

<ehcache:annotation-driven/>

shared (デフォルト) および methodの self-populating-cache-scopeには 1 つのオプションがあります。違いは何ですか？

selfPopulatingフラグ付きの注釈@Cacheableもあります

私がいくつかの投稿で読んだことによると

http://groups.google.com/group/ehcache-spring-annotations/browse_thread/thread/7dbc71ce34f6ee19/b057610167dfb815?lnk=raot

共有が使用されると、インスタンスが1つだけ作成され、同じキャッシュ名が使用されるたびに同じインスタンスが使用されるため、 1つのメソッドに対してselfPopulatingフラグをtrueとして使用すると、

selfPopulating フラグが true に設定された @Cacheable で注釈が付けられた 他のメソッドにアクセスしようとするすべてのスレッドは保留状態になりますが、これは望ましくありません

<ehcache:annotation-driven/>

一方、self-populating-cache-scope = methodの場合、 @Cacheable で注釈が付けられたすべてのメソッドに対して個別のインスタンスが作成され、 selfPopulating フラグが true に設定されているため、問題は発生しません。

しかし、この場合、@TriggerRemoveを使用して要素を削除しようとすると、@Cacheable で使用されるキャッシュ名を指定すると、それらの個別のインスタンスのそれぞれを検索して値を見つけますか? これはオーバーヘッドではありませんか？

4

1 に答える 1

1

上記の ehcache Google グループで Eric が回答

いずれの場合も、基礎となる Ehcache インスタンスが 1 つあります。selfPopulating=true を設定すると、SelfPopulatingCache ラッパーが作成されます。

cache-scope=shared の場合、その名前付きキャッシュを使用するすべてのアノテーションは同じ SelfPopulatingCache ラッパーを使用します cache-scope=method の場合、メソッドごとに 1 つのラッパーが作成されます

どちらの場合も、SelfPopulatingCache はラッパーであることに注意してください。ラッパーをサポートする実際のキャッシュは 1 つだけです。

ブロッキングに関しては、SelfPopulatingCache と BlockingCache のドキュメントを読むと、キャッシュ レベルのロックとキー ストライピングによるキーごとのロックの間で ehcache が妥協していることに気付くでしょう。 http://ehcache.org/apidocs/net/sf/ehcache/constructs/blocking/BlockingCache.html

于 2012-04-12T19:13:23.517 に答える