Hibernate version:
3.1.3

We had Problems with upgrading to Hibernate 3.1 (from 2.1) on an Environment that uses 400+ Databases, all with the same mappings. We got "OutOfMemoryError: PermGen Space" and quickly found out that the permanent generation got filled up with CGLIB-enhanced entity classes. Each database generated their own (altho all used the same entities) bc. each database was accessed using a separate SessionFactory (as recommended).

Digging into the code that generated these classes we found that the CGLIB class cache, that would allow to reuse once generated glasses, is deactivated by default. Following code from CGLIBLazyInitializer.getProxyFactory():

try {
Enhancer en = new Enhancer();
en.setUseCache( false );
en.setInterceptDuringConstruction( false );
...

We activated the cache by changing the code to en.setUseCache(true) and found that this solves our problem. The classes are no longer generated per database but used across all databases.

Is there a special reason for the deactivation of the cache (it still is in hibernate 3.2)? Should we expect problems from enabling it?

At least in one thread of this forum someone recommended enabling the class cache to workaround serialization problems. So I assume it should be ok to do so. But I would like to know what considerations lead to the decision to disable it, so I can judge if it has implications in our situation.

Thanks for any thoughts!

It was changed to save resources for typical use cases (single session factory ) I see it was a bad idea, patch it.

what would/will this save for the typical use case baliukas ?

wouldn't enabling it leak memory in another way instead ? e.g. keeping references to undeployed classloaders ?

As I remember it was a problem with "hot deployment", but JVM unloads cached CGLIB classes in my tests. I can not reproduce any problems with this cache. SessionFactory scope proxies is more "safe" way (probably it was too paranoid decision).

@baliukas: Thanks for your help!

@max: The CLIB class cache uses a WeakHashMap keyed with the ClassLoaders that "loaded" the generated classes, so classes from undeployed ClassLoaders should get gc'd.

Anyway, If this patch is too unsafe and not relevant to the typical usecase, why not make it configurable as sysproperty, so us untypical users do not have to patch the product to get what we want. It might be a seldom problem, but it is a showstopper if you have it.

Searching the forum for "PermGen" it seems that other people already encountered similar problems.

yes i'm just curious on wether this is *the* permgen issue.

If cache=true allows for gc collection of unreferenced classes,
why does cache=false still result in permgen growing ?

The gc collection of unreferenced classes is dependent on the gc of their classloader. Only when the classloader is dropped the WeakHashMap will remove the cached classes.

In most cases, as in mine, this is the WebApp class loader. As our web application tries to connect 400+ DBs, all in the context initialisation, this loader of course remains, so the PermGen runs full.

I think some issues, found on the INet, with PermGen errors in development systems are quite similar, where the Appserver fails to dereference old WebApp class loaders after a hot deploy (like here: http://forum.springframework.org/showthread.php?t=21383)

I think enabling the cache will help in cases where many SessionFactories are created based on the same mapping, while the classloade remains (like here: http://forum.hibernate.org/viewtopic.ph ... emoryerror).

It will of course not help with PermGen errors from using mappings for 1900+ different tables like here: http://forum.hibernate.org/viewtopic.ph ... ht=permgen.

guys, Hibernate 3.2 doesn't call this method anymore; could you check if life is easier on 3.2 for you ?

You are right. We checked hibernate 3.2 again and we don't see increasing permgen there any more. The cache is already enabled.

We thought we had already checked that, but obviously there was an error in our test. Sorry for the inconvenience and have a nice day.

You work with OC4j Application Server?

No, we used Tomcat 5.5.