I did a lot of this kind of bugs myself too and it is very trivial to fix. 1. Set maxConnections to 1 for testing 2. Use lazy decorator for connection to throw exeption from "close" 3. Use "find/replace" to remove all "}finally{ connection.close(); }" 4. Store decorator in ThreadLocal and close connection in single place per application.
I am sure we are talking about web applications and it is very trivial to close connection in controler or to implement Filter for Model 1 web application, but this solution works for any kind of applications, I use it for JMS too. BTW it is not a very big overhead in the most of my use cases (application and DB on the same machine or LAN) if pool opens a new connection per thread without "autoreconnects" and any kind of workarounds. > Juozas Baliuka wrote: > > I like innovations, but try to implement and test it at home please. > > I am sure there are not so many situations in the real world need this > > "feature". > > It takes a few minutes to find connection leak and to fix it in any > > applications, doe's not it ? > > It does not. > > I have 2 new clients in the past 3 months (one medium, and one huge > highly publicized screwed-up government project) that both have > connection leak issues that they have been working at for a long time. > > -- > Serge Knystautas > President > Lokitech >> software . strategy . design >> http://www.lokitech.com/ > p. 1.301.656.5501 > e. [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]