commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Nielsen <gl...@mail.more.net>
Subject Re: [DBCP] AbandonedTrace - Connection Recovery
Date Wed, 23 Jul 2003 14:08:01 GMT
David Graham wrote:
> --- Glenn Nielsen <glenn@mail.more.net> wrote:
> 
>>David Graham wrote:
>>
>>>--- "Laird J. Nelson" <lairdnelson@comcast.net> wrote:
>>>
>>>
>>>>>-----Original Message-----
>>>>>From: John McNally [mailto:jmcnally@collab.net]
>>>>>Why is this such a contentious issue?
>>>>
>>>>FWIW, because some users have business experience, and some do not.
>>>>Those who do recognize that business *runs* on stopgap solutions.  The
>>>>fewer of those stopgap solutions you have to write, the better, IMHO.
>>>
>>>
>>[SNIP]
>>
>>
>>>This is absolutely not a DBCP code issue; it is a management issue. 
>>>Applications that leak resources should have their own separate
>>
>>connection
>>
>>>pool.  When they run out of connections, only that app will break and
>>>won't affect any other applications on the server.  It will be much
>>
>>easier
>>
>>>to debug the leak in the isolated app because DBCP won't hide it from
>>
>>you
>>
>>>and you won't have to search any other apps.
>>>
>>>So, there is no need for this feature in DBCP if the above process is
>>>followed.  This makes everyone's life simpler :-).
>>>
>>
>>A web application which leaks db connections until it exhausts its pool
>>can impact other applications running on the app server.
>>
>>What happens is that the broken app ends up sucking up resources for
>>each concurrent request being made to it which is waiting for the
>>db connection timeout.  Usually this is set to 5-10 seconds.
>>This can suck up alot of resources.  Memory, threads, etc.
> 
> 
> Right, I meant that it won't affect the database operations of other apps.
>  The bottom line is that DBCP shouldn't try to fix broken code.  There are
> many ways an app can break, connection leaks being one of them.  It's not
> our job to fix all the broken code in the world.  There needs to be a
> clearly defined separation of concerns between DBCP and client code. 
> Resource cleanup is clearly in the domain of the client.
> 
> I get the impression that some of you believe connection cleanup is
> difficult.  It really is trivial to properly dispose of connections in a
> finally block.  It's even easier to find problems if you've properly
> layered the app so the database calls are all in one place.
> 

I am really getting tired of the 'purists' in this discussion telling
the 'realists', "Just fix your code".

That is not the issue at all.  Those who are advocating to retain this
feature are doing so from an application server admin perspective.
When I have had to deal with this problem as the application server
admin there are many times when I don't even have access to the code.  
Its the customers code.

And yes, my organization does provide our customers with guidelines
with Do's and Dont's when writing web applications which includes a
discussion of db connection pooling and how to make sure the
db connection is closed properly.

Regards,

Glenn


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


Mime
View raw message