I know how you feel. DBCP won't save you in these cases; training people in the simple ways of cleaning up resources properly will.
Yeah, I have plans on how to spot these issues better ahead of time. Also, just starting to use p6spy as my magic bullet in the short-term...
It is not the pool's responsibility to clean up after poorly coded apps. There is a clear separation of concerns between the pool and the app. The
pool maintains the connections, the app properly uses the API and returns
all connections when finished with them. There is no sound algorithm for
determining when a connection is abandoned because DBCP doesn't have all
the information required to make that decision. There are more but I've
stated them previously.
I disagree about the lack of a sound algorithm, but I have come to agree about this not being the pool's responsibility. So I agree the pooler should just try to avoid opening connections each time (general pool issues), and not get into these application issues.
For some reason there are people against adding commons-logging to DBCP. I don't know of any good reason not to.
I think it's just because it's to keep the dependency tree thin. I haven't been burned yet, but in some of my apps I have dependencies on common libs from 5 higher level apps. I think eventually I'll get burned by 2 different apps requiring 2 different versions of commons-beanutils (just to pick one).
-- Serge Knystautas President Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
