Yes, I know, this is a Hibernate forum and not a c3p0 forum, but I figured that enough of you are using c3p0 that you might have some insight into a problem that's occurring. I've posted the issue to the c3p0-users mailing list, but so far I haven't had any luck figuring it out.

Anyway, as I'm sure you can tell by now, I'm using c3p0 for connection pooling in Hibernate. We're hoping to use Hibernate as the persistence layer in the next version of our application under Tomcat. However, we're having a problem that we've been unable to diagnose.

After Hibernate has been up and running for a while we'll start to see the following exception:

and a lot of the following errors:

We have the c3p0 connection pools configured in the hibernate.cfg.xml file as follows:


The class being referenced, BasicResourcePool$5, does indeed exist in the c3p0 jar file. We're using the jar file that comes packaged with the Hibernate download.

Any ideas?

-Matt

Hi -
I've seen this problem with c3p0, as well as some other third party jars we are using (syslog, jcs cache).

The problem is that some daemon threads are launched during init to perform some useful tasks. However, there is no way to *force* these threads to terminate - they assume that they should be run until the vm is terminated.

The problem "NoClassDefFoundError" exception appears when a thread is still running, but it refers to some class that has been unloaded.

I think the typical scenario is that Tomcat has been "reloaded" - that is, the webapp has been reloaded. In that case, Tomcat will unload classes, and re-init the webapp. This causes 2 problems:
1. daemon threads left running will continue to run, but will throw exceptions when the find out their classes have been unloaded

2. since the webapp is re-inited, the webapp will typically re-spawn similar threads upon reload. So for instance, if c3p0 relies on 3 daemon threads for monitoring etc, reloading your webapp the first time will result in 6 daemon threads running - 3 bogus thread, and the 3 new threads. This will evetually pile up and cause problems after serveral/many reloads.


I have not found a good solution to this problem, other than NOT using Tomcat's reload feature.

If there is a way to force shutdown of these threads, the problem could be solved by killing these threads in a context listener. However, none of these packages (c3p0, syslog, jcs cache) provide this functionality, as far as I know. (I wish someone would tell me otherwise...)

Regards,
Tyson