Hi,

We have just upgraded from Hibernate 2.1.7 to Hibernate 3.0, running on both JBoss 4.0.2 and JBoss 4.0.3. In terms of databases, we use HSqlDB, MySQL and MS SQL Server. For platforms, we have a combination of Mac OS X and Linux (Redhat and Ubuntu). We have tried to explore this problem with both no 2nd level cache and with JBoss Cache (using Sleepy Cat Berkley DB in development). We have loaded the JBoss to use heap sizes from 128/256 MB to 512/768 MB.

The application appeared to run fine until we got to a moderately complex object graph relationship with only minimal data (10s to 100s of domain objects). The system would perform all of the hibernate activities to retrieve the objects necessary, even finalizing the session. However, rather than returning control to the invoking service to package the results for the web tier, the JBoss server went into terminal garbage collection - effectively three plus minutes of scavenging (as opposed to full garbage collection).

This is very strange, effectively rendering our application useless. We have run this application in production for a year now, in the Hibernate 2 land so I am slightly worried about the changes introduced by Hibernate 3 now. Does anyone know of any changes that could have provoked this GC activity?

Sean.

try "-XX:MaxPermSize"

Thanks for the reply...

Relative to the maximum heap size, how big should this be? We tried increasing it to 128MB but that did not solve the GC problem.

Many "old" objects provoke it. Try to monitor GC activity http://java.sun.com/performance/jvmstat/visualgc.html if "MaxPermSize" setting doe's not help (128MB for permanent memory is a "large" number, it is used for reflection related data like class objects).

Hi,

Right, I see. The problem is obviously old objects as you say.

We think the underlying problem is that we have a particular object graph that falls foul of the n+1 problem in that it has lots of circular references, linked list style references and so on. We are going to re-design this object graph to be cleaner - in the hope that it resolves this issue for us.

Also, we had two domain objects that were not lazily loaded - this can't help in terms of hydrating lots of objects into the fist level cache as part of larger transactions.

When we deploy this to a multi-processor server, I am wondering about using parallel garbage collection on one of the processors (if we have 4 cores say, available to us).

Thanks for your input.

Sean.