Hi, I have a project built around hibernate 2.0.1. Things were going well until we did a series of updates to our CVS repository that resulted in hibernate pitching a lot of "WARNING: unclosed connection" messages. These connections then gobble up all the available connections in the pool and lock up the system, I have to restart Tomcat. Has anyone out there experienced this? If so is there a simple explanation. I am trying to trigger the autoClose flag as an ad Hock solution, but I'd like to get to the root of why my connections are no longer closing through no change in my code.

are you including your *.class into CVS control too?

Your source might say something. but your compiled classes could be different...

Our class files are not stored in the repository, we simply store the source code and rebuild it when we update. If there is no other explanation I would be willing to entertain that. But I think its unlikely, I think its far more likely that this is a configuration error of some kind.

I have managed to trigger autoClose but that doesn't seem to solve anything. I'm close to running out of ideas at this point.

I am quite sure there was some change on your code or config in the process. Look for unclosed sessions or something like that.

We have looked for unclosed sessions and found them. This never happened before we did the merge and I think this kind of behavior puts the fault somewhere in the connection pooling. I have scoured the source for c3p0 and cannot find an explanation. I have placed breakpoints in the hibernate source near the sections that deal with open sessions and none of them are tripped. Yet I get messages about the sessions. this really doesn't make any sense to me. Moreover a google search reveals scant few other cases like this. So I am hoping someone here may know something about SessionImpl and how it could be producing this behavior.

I am also having this problem, and I just switched to the c3p0 connection pool, was there ever a resolution? I believe I'm closing all sessions properly as well so I'm interested in anything you've found out.

Thanks.

I've been doing some experimenting over here and it seems that although we have some "unclosed connection" warnings in our logs - when using the hibernate default pool, even set to a very low value, our server will not lock up. However, if we switch to the c3p0 pool then no matter how large we make the max connections, those connections will eventually be consumed and the application will lock.

So for now we're back on the default hibernate pool, but I'd be interested in hearing other's experiences.

I really, strongly recommend that you consider the fact that it is you application not closing sessions. Every single time anyone has ever had this problem, that was the cause.

I think it's a given that my application is no longer closing sessions. The problem is that I was closing my sessions appropriately before this configuration error occured. Now the connection pool doesn't close it's expired connections and I am trying to ascertain why. I switched to the apache connection pooling and while it is obvious the connections are left open, at least apache is closing and reclaiming them.

As an update, I've gone through my application and fixed all situations where the session might be closed by the finalizer, so I no longer get any warnings from hibernate, however the c3p0 problem is persisting.

However, I am not ruling out an Oracle specific problem here since when on the Hibernate default connection pool we see a number of lingering processes over the maximum number of connections I allow for the pool. In c3p0 we never go over the limit, but the server eventually locks up.

Hi Matt!

Are you using Tomcat and c3p0?

Because I have had problems with the "reload" feature of Tomcat which obviously not ends c3p0's daemon threads but creates new ones without closing the old ones at each "reload" command. This always ends up with unexpected behaviour, possibly memory/resource leaks, and ClassNotFoundExceptions...

Sincerely,

/F

I think you need to close session factory in context listener to solve this problem and do not forget to close session at the end of request, the most simple way is to close thread local session in filter.
Refactor app if you have code dublication in resource management, it must be trivial to remove "session.close()" and to move it to filter.
Test it with pooled connections and with plain connections, both ways must work if resource management is not broken.