Commons Connection Pool -Why is remove-abandoned deprecated?

[starki78 <st...@libero.it>]

Hi!
I make thoughts of using the
Commons Connection Pool
perhaps also the tomcat-implementation)

One very interesting feature is
remove abandoned,
if connections in a pool are not closed
they will be closed after
being unused for a while.
Everything that deals around this shall be
removed in the following versions like 
org.apache.commons.dbcp.AbandonedConfig

My question is simple why will it removed 
and is there
an alternative??

Thanks a lot for input!!
Starki


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org

Re: Commons Connection Pool -Why is remove-abandoned deprecated?

[Craig McClanahan <cr...@apache.org>]

On 4/6/06, starki78 <st...@libero.it> wrote:
>
> Hi!
> I make thoughts of using the
> Commons Connection Pool
> perhaps also the tomcat-implementation)
>
> One very interesting feature is
> remove abandoned,
> if connections in a pool are not closed
> they will be closed after
> being unused for a while.
> Everything that deals around this shall be
> removed in the following versions like
> org.apache.commons.dbcp.AbandonedConfig
>
> My question is simple why will it removed
> and is there
> an alternative??


I'm not an active DBCP committer so this is just my personal opinion, but
the "remove abandoned" functionality was a mistake that never should have
been added in the first place.

The theory of this feature was that, if an application forgot to close an
allocated connection (which returns it to the pool), then the pool would
eventually clean up that connection so you don't run out.  In other words,
it is a hack to work around a bug in the calling application, which should
*always* ensure that allocated connections are returned, no matter what kind
of exceptions occur.  So, from that perspective, I would encourage users to
fix their apps (typically by using try/catch/finally or something like
that).

The more insidious problem, however, is that the logic has to make the
assumption that the connection was actually abandoned -- and it has no good
basis on which to make that judgement.  The best it can do is assume that,
after a certain amount of time, the connection was just forgotten about.  If
you have a long running transaction that takes longer to execute than
whatever you set the timeout for, the abandoned connection logic is going to
swipe a connection you are actually using, and cause your application all
sorts of grief.

The alternative is to ensure that your application never leaks connections.
Then, you won't have any abandoned connections to worry about :-).

NOTE -- this is not the same as the logic to close down *idle* connections
that actually did get returned to the pool.  That kind of thing is OK,
because it can reduce resources allocated to your DB during periods of low
activity (although in practice it may or may not make any real difference --
it's worth doing performance testing to see if it is worth anything in your
scenario).

Thanks a lot for input!!
> Starki


Craig