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]
