I have only had a cursory read through this - using someone elses (hopefully better tested both in unit and real world) implementation is better than writing your own...
...however any system attempting to remove resource cleanup responsibilites from the developer either has to place extremely restrictive constraints on the use or sacrifice optimal resoucre utilization. if you don't need optimal resource use then or can handle the constraints then by all means work within a framework - just remember that if you ever change your situation to requiring optimal use or working outside the constraints you have a problem. Matt > -----Original Message----- > From: Juozas Baliuka [mailto:[EMAIL PROTECTED] > Sent: 23 July 2003 11:34 > To: Jakarta Commons Developers List > Subject: Re: [DBCP] AbandonedTrace - Connection Recovery > > > > > You misunderstand me. http://www.springframework.org/ I have > never used this > framework, but I use the same ideas. > > > > 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 > > > > useful > > > > > 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. > > > > Ahhh now I see what you are doing - this then requires > maxConnectionsInPool > > == max threads or the app will break under heavy load, not > IMO a good > design > > decision. > > > > > 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. > > > > > > The simplest way to avoid requiring the use of such approaches or of > > abandonded connection reclamation is to do the exacty > oppositie of 3. any > > call which genuinely brings a connection into active play > (get from pool, > > use datasource, DriverManager etc should include a finally > block closing > the > > resource. If this is followed there will be no problems > with leaks and an > > optimal put back in pool strategy is possible. If there is > no need for a > > call to open a connection it is not opened (you could > achieve this on your > > method with the lazy decorator but at the cost of maintaing it). > > > > finally blocks are one of the great benefits of using a > modern high level > > language - use them. > > > > If I am reviewing someone else's code I search for every connection > opening > > and statement creating and require a corresponding finally > block to close > > them. If I am responsible for quality gating outsourced > code I do the > same. > > > > If we purchase a library that does this I will likely never > recommend we > use > > it or that company again... > > > > I see why people desire a stop gap solution but as this message > indicates - > > shortcuts to doing proper resource management will be looked for and > > (ab)used if they exist - frequently incorrectly... > > > > Matt > > > > > ************************************************************** > ************ > > The information transmitted herewith is sensitive > information intended > only > > for use by the individual or entity to which it is addressed. If the > reader > > of this message is not the intended recipient, you are > hereby notified > that > > any review, retransmission, dissemination, distribution, > copying or other > > use of, or taking of any action in reliance upon this information is > > strictly prohibited. If you have received this > communication in error, > > please contact the sender and delete the material from your > computer. > > > > > --------------------------------------------------------------------- > > 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] > ************************************************************************** The information transmitted herewith is sensitive information intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
