Question

While c3p0 removes a connection after the maxIdleTime, it adds it to an internal weakHashMap named formerResources in BasicResourcePool. This map is getting piled up on the heap with JDBC4Connection objects and gets cleared only on GC. Is it possible to opt out for such collection or is there any clear advantage of such collection?

Was it helpful?

Solution

the purpose of formerResources is just to permit checkins of c3p0 resources to be idempotent while at the same time check-ins of foreign resources -- Connections never before seen by the pool -- provoke a warning.

in practice, for most c3p0 users, it is hard to check-in a foreign resource at this level. the BasicResourcePool is buried beneath a proxy and then a C3P0ConnectionPool object. but BasicResourcePool itself intends to be generally usable, potentially outside of c3p0. "checking in" a foreign resource likely implies a significant bug, and resources thus "checked in" will neither be managed by the pool nor genuinely destroyed. so it's important that BasicResourcePool warn when this occurs. but it's also important that c3p0 not warn if a user has checked in the same resource multiple times: we want it to be permissible for clients to err on the side of over-checking in (because the pool can ignore a second check-in, but a failure to check-in at all implies a resource leak). so c3p0 needs to be able to tell the difference between resources it has once managed but has now purged (don't warn, an extra checkin is useful caution) and resources it has never managed (must warn, likely a programming error and resource leak).

does that make any sense?

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top