Second Level Cache, Garbage Collection and Performance

[blueEinstein2]

Ran across this article, which states that:

...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

My question is, supposed one http request to our home page loads X java object instance. So, that means if there are Y visitors every second, then it will create X * Y java objects instance per second; which is not efficient and will have to be cleaned by GC eventually.

Is the above theory accurate? If so, is it possible to configure hibernate to store objects instead of values only? That way, GC won't have to work so hard?

[jonnio]

Well, I'm pretty sure the values are stored in a hashtable with some keys so I don't think GC is working harder than it has to anyway. Most JVMS, JRockit in particular, have good ways of dealing with lots of little short and long lived objects anyway. You should be able to tune the performance of your app by tweaking the hibernate setup and the jvm settings to achieve the performance you are looking for.

[blueEinstein2]

Sorry, didn't make my question clear enough. I agree that it's probably stored in hashtable.

However, I was hoping that if somebody requests for an object, it would not return a new instance of the object, but rather, a reference to the existing object.

Seems like inefficient to keep creating short lived object x times. Or is there no way around this?

[karldmoore]

I think what it was saying was the properties are stored and not the objects, but if you hit the cache, Hibernate re-contitutes the object from the cached data. Hence you aren't going to hit the DB.

Hibernate calls this state that the objects are in 'dehydrated', as it is all the important bits of the object, but in a more controllable form for Hibernate. I'll use the terms 'dehydrate' and 'hydrate' to describe the process of converting between this broken apart data into an object of your domain (hydrating being the process of creating an instance of your domain and populating it with this data, dehydrating being the inverse).