Steve Waldman - 2007-07-04

Logged In: YES
user_id=175530
Originator: NO

So, you know, there's a lot you could investigate here.

On the c3p0 side, it'd be nice to know what version you're running, and what config actually got through to c3p0. c3p0 logs a version banner and configuration dump at INFO to help you check this stuff.

As far as c3p0 is concerned, are the Connections being closed? Try setting logging of com.mchange.v2.resourcepool.BasicResourcePool to DEBUG or FINEST, and you can watch c3p0 conduct tests of idle connections, and decide to expire them. From the c3p0-side do any Connections remain open? Via DEBUG logging, use of jconsole or some other JMX tool, or programmatic queries against the DataSource, you might check the size of the pool as c3p0 sees it.

Why would this be different from the number of open TCP connections? Maybe it would, maybe it wouldn't. That depends on your driver. A database Connection needn't, and probably oughtn't, map one-to-one to a TCP/IP open socket. Perhaps your database driver is clever, and opens a small pool of Sockets over which the work of multiple database Connections is multiplexed. In this case, it's quite possible that all Connections could be closed, but the driver would maintain several open Connections, at least until some timeout. Have you done the same test without c3p0? What's the behavior?

Anyway, there's a lot you can do to try to track this down. Please first verify, via logging or JMX, that c3p0 internally is (or is not) closing Connections as you expect. If you watch the logs, it'll probably be pretty clear why Connections aren't closing if they're not.

If, as far as c3p0 is concerned, Connections are being closed, look into your driver's behavior with respect to the relationship between sockets and database Connections.

Good luck!