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.

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.

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.

Yes. It was introduced in Ehcache 2.1.

Ehcache is a “transactional” cache for Hibernate purposes. The net.sf.ehcache.hibernate.EhCacheRegionFactory has support for Hibernate entities configured with <cache usage="transactional"/>.

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 this Hibernate bug report: https://hibernate.onjira.com/browse/HHH-2224.

Hibernate identifies cached entities using an object id. This is normally the primary key of a database row.

Yes.

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.