FAQ
If I use BigMemory Go with my application and with Hibernate for second-level caching, should I try to use the CacheManager created by Hibernate for my app's caches?
While you could share the resource file between the two CacheManagers, a clear separation between the two is recommended. Your application may have a different lifecycle than Hibernate, and in each case your CacheManager "Automatic Resource Control" settings might need to be different.
Should I use the provider in the Hibernate distribution or in BigMemory Go's Ehcache?
Since Hibernate 2.1, Hibernate has included an Ehcache CacheProvider. That provider is periodically synced up with the provider in the Ehcache Core distribution. New features are generally added in to the Ehcache Core provider and then the Hibernate one.
What is the relationship between the Hibernate and Ehcache projects?
Gavin King and Greg Luck cooperated to create Ehcache and include it in Hibernate. Since 2009, Greg Luck has been a committer on the Hibernate project to ensure Ehcache remains a first-class second-level cache for Hibernate.
Does BigMemory Go support the transactional strategy?
Yes. It was introduced in Ehcache 2.1.
Are Hibernate transactions supported?
Ehcache is a "transactional" cache for Hibernate purposes. The net.sf.ehcache.hibernate.EhCacheRegionFactory has support for Hibernate entities configured with <cache usage="transactional"/>.
Why do certain caches sometimes get automatically cleared by Hibernate?
Whenever a Query.executeUpdate() is run, Hibernate invalidates affected cache regions (those corresponding to affected database tables) to ensure that no stale data is cached. This should also happen whenever stored procedures are executed.
For more information, see the Hibernate issue HHH-2224 at :
https://hibernate.atlassian.net/browse/HHH-2224.
How are Hibernate entities keyed?
Hibernate identifies cached entities using an object id. This is normally the primary key of a database row.
Are compound keys supported?
Yes.
I am getting this error message: "An item was expired by the cache while it was locked." What is it?
Soft locks are implemented by replacing a value with a special type that marks the element as locked, thus indicating to other threads to treat it differently than a normal element. This is used in the Hibernate Read/Write strategy to force fall-through to the database during the two-phase commit. Although we don't know exactly what should be returned by the cache while the commit is in process, the database does. If a soft-locked element is evicted by the cache during the two-phase commit, then once the two-phase commit completes, the cache will fail to update (since the soft-locked element was evicted) and the cache entry will be reloaded from the database on the next read of that object. This is obviously non-fatal, but could cause a small rise in database load.
So, in summary the Hibernate messages are not problematic. The underlying cause is that the probabilistic evictor can theoretically evict recently loaded items. You can also use the deterministic evictor to avoid this problem. Specify the -Dnet.sf.ehcache.use.classic.lru=true system property to turn on classic LRU, which contains a deterministic evictor.