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]
