Greetings,

I'm trying to tune my Ehcache settings to deal with an issue of running out of old gen heap space. The current setup is MemoryStore only (overflowToDisk=false), Hibernate 3.3.1, and Ehcache 1.7.2.

According to Hibernate: Truly Understanding the Second-Level and Query Caches, "The first thing to realize about the second-level cache is that it doesn't cache instances of the object type being cached; instead it caches the individual values for the properties of that object." While I see all the individual properties in a heap dump of our app under the net.sf.ehcache.store.MemoryStore for each net.sf.ehcache.Cache, I'm also seeing that they each contain an org.hibernate.cache.CacheKey for each entity, and each of those holds on to a reference to the actual entity instance as its 'key' property. The CacheKey reference seemingly prevents the entire instance graph from ever being GC'd (unless a given key is pushed out of the cache of course). This is accounting for a majority share of my retained heap, and seems to coincide with my old gen "memory leak".

My question is could I be configuring something incorrectly that the CacheKey's are holding references to all my actual entity instances (as opposed to their Long id's or something), or is that how it's intended to work?

Thanks,

Ian

I tried upgrading to Hibernate 3.6.1 and Ehcache 2.3.2. I get a rather different dominator tree, but in the end I'm still finding a reference to the cached entity held by CacheKey.key:

A quick update:

After much debugging on 3.6.1.Final I'm definitely finding that certain entities are being cached as their own CacheKey.key's, as opposed to their IDs being used. A quick exchange with Steve Ebersole on IRC confirmed that this isn't intended behavior. It seems to happen especially with entities that have composite keys.

I'm also finding it for entities with a single Long ID. In this case the entity has a unidirectional one-to-many set of entities with composite keys, joined by named properties.

I finally found this resolved bug that appears similar: http://opensource.atlassian.com/project ... e/HHH-3383. It's for QueryKey.key's, but lower down in the comments a user adds that they're seeing it for CacheKey.key's just as I am.