#8 C3P0 not recycling connections

[speters]

We have recently encounted an issue with our connection
pooling. It seems that c3p0 is not recycling
connections as it should.

We have not noticed any exceptions being thrown, and
thorough code checks show that we are making the
close() call inside a finally block.

In an effort to troubleshoot this problem, we isolated
one pool and setup a test class to make simple dababase
calls then close the connection. We found that after
every connection in the pool was used, we were not able
to acquire a new connection. The number of connections
held in the pool before this occurred was always less
than the maximum we had set. We found that adjusting a
few properties (acquireIncrement, maxPoolSize,
initialPoolSize and maxIdleTime) would allow us to
increase the number of connections we could use before
running into problems, but, in the end, never actually
solved the issue. The most connections we were able to
use until the pool was exhausted was 39. This was with
the acquireIncrement set at 5, maxPoolSize at 75,
maxIdleTime at 60, and initialPoolSize of 20. We also
tried adjusting the number for numHelperThreads, but it
didn't seem to make any difference.

Our environment has mutiple applications running on one
Tomcat instance. Each application has mutiple pools it
must draw from, and each application has it's own uique
set of pools. We are also using Hibernate 3.0 and MySQL.

We were using c3p0 9.0-pre4 when we noticed this
problem. We just downloaded and installed 9.0-pre6 to
see if this would eliminate the problem and it did not.
In fact, for this situation, there was no difference in
how our application or test runs behaved.

Please let me know if there is any other information
that can help debug this issue.

Thank you.

[Steve Waldman]

Logged In: YES
user_id=175530

First, I'm sorry for the unforgivable nonresponse. I'm
reviewing outstanding issues today, and boy, more than a
year is a long time to wait. I'm not sure what to tell you,
except to say that what you observered, oh so long ago,
sounds like the behavior c3p0 would have exhibited if
somehow, despite your diligent code checks, Connections were
failing to be returned to the pool. I'm sure you've moved
on, one way or another, from this issue, but if it remains
at all relevant, you can try c3p0-0.9.1-pre7, and set the
unreturnedConnectionTimeout parameter to some positive value
(longer than any legitimate operation might require). If
indeed c3p0 does have to clean up some unreturned
Connection, set debugUnreturnedConnectionStackTraces to
true, to see the stack traces that checked out the
Connections that c3p0 ended up cleaning up for you.