Note that there are some explanatory texts on larger screens.

plurals
  1. POAvoiding multiple repopulations of the same cache region (due to concurrency)
    primarykey
    data
    text
    <p>I have a high traffic website and I use hibernate. I also use ehcache to cache some entities and queries which are required to generate the pages.</p> <p>The problem is "parallel cache misses" and the long explanation is that when the application boots and the cache regions are cold each cache region is being populated many times (instead of only once) by different threads because the site is being hit by many users at the same time. In addition, when some cache region invalidates it's being repopulated many times because of the same reason. How can I avoid this?</p> <p>I managed to <a href="https://stackoverflow.com/questions/1518808/using-ehcache-blocking-decorator-with-hibernate">convert 1 entity and 1 query cache to a BlockingCache</a> by providing my own implementation to hibernate.cache.provider_class but the semantics of BlockingCache do not seem to work. Even worst sometimes the BlockingCache deadlocks (blocks) and the application hangs completely. Thread dump shows that processing is blocked on the mutex of BlockingCache on a get operation.</p> <p>So, the question is, does Hibernate support this kind of use?</p> <p>And if not, how do you solve this problem on production?</p> <p><strong>Edit</strong>: The <em>hibernate.cache.provider_class</em> points to my custom cache provider which is a copy paste from <a href="http://ehcache.org/xref/net/sf/ehcache/hibernate/SingletonEhCacheProvider.html" rel="nofollow noreferrer">SingletonEhCacheProvider</a> and at the end of the start() method (after line 136) I do:</p> <pre><code>Ehcache cache = manager.getEhcache("foo"); if (!(cache instanceof BlockingCache)) { manager.replaceCacheWithDecoratedCache(cache, new BlockingCache(cache)); } </code></pre> <p>That way upon initialization, and before anyone else touches the cache named "foo", I decorate it with BlockingCache. "foo" is a query cache and "bar" (same code but omitted) is an entity cache for a pojo.</p> <p><strong>Edit 2</strong>: "Doesn't seem to work" means that the initial problem still exists. Cache "foo" is still being re-populated many times with the same data, because of the concurrency. I validate this by stressing the site with JMeter with 10 threads. I'd expect the 9 threads to block until the first one which requested data from "foo" to finish it's job (execute queries, store data in cache), and then get the data directly from the cache. </p> <p><strong>Edit 3</strong>: Another explanation for this problem can be seen at <a href="https://forum.hibernate.org/viewtopic.php?f=1&amp;t=964391&amp;start=0" rel="nofollow noreferrer"><a href="https://forum.hibernate.org/viewtopic.php?f=1&amp;t=964391&amp;start=0" rel="nofollow noreferrer">https://forum.hibernate.org/viewtopic.php?f=1&amp;t=964391&amp;start=0</a></a> but with no definite answer.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload