Hmmm. This sort of thing is hard to debug, but here are some thoughts.
1) Do an exhaustive search of any part of your filesystem that might somehow get into the effective classpath of an websphere application or component, and make sure there is no more than 1 c3p0-*.jar file anywhere (this includes jars that might be wrapped in wars or ears!);
2) Make sure that your application components are all properly cleaned up when you do hot restarts of your application. Are any c3p0 DataSources being properly closed and cleaned up on a hot restart?
3) Try upgrading to the latest version of c3p0. There was an issue where under some circumstances, c3p0 would hold a static reference to a ClassLoader, preventing the ClassLoaders from being garbage collected. This is resolved in the latest c3p0-0.9.1-* builds. There might be some kind of issue where the appserver is trying to reload c3p0, but that somehow conflicts with a stale version already loaded.
Note that several of these suggestions are about reloading c3p0. If you shut down WebSphere entirely, so that no WS JVMs are running at all, and then start up your app, do you see this error initially, or only after some time, or an app change and redeployment?
Also, when you see the error, try to get a dump of JVM stack traces, and see if any c3p0-related threads (look for com.mchange in the stack traces) are running. This might indicate live threads are keeping a previous classloader's c3p0 around, while you're trying to load a new one.
Others have reported this sort of issue involving WS and ant: [
http://www-128.ibm.com/developerworks/forums/dw_thread.jsp?forum=275&thread=31014&cat=9 ]
Good luck!
Steve
Login
FAQ
Search
