DBCP not ready for production server?

[Rosdi Kasim <ro...@epantai.com.my>]

Is this true?

http://216.239.57.104/search?q=cache:mX0TKkjHWLMJ:stealthis.athensgroup.com/presentations/White_Papers/Jakarta_Pooling.doc+dbcp+connection+pool+leak&hl=en&ie=UTF-8

If it is.., what (free) alternatives I have?..

Re: DBCP not ready for production server?

[Rodney Waldhoff <rw...@apache.org>]

On Fri, 18 Jul 2003, Rosdi Kasim wrote:

> Is this true?
>
> http://216.239.57.104/search?q=cache:mX0TKkjHWLMJ:stealthis.athensgroup.com/presentations/White_Papers/Jakarta_Pooling.doc+dbcp+connection+pool+leak&hl=en&ie=UTF-8

I use DBCP in production 24x7 for several large scale applications, both
desktop and server based, on dozens of platforms (the desktop ones anyway)
against two different database engines, and I have done so for years
without any major issues.

Your mileage may vary.

Danny's comments seem spot on.

- Rod <http://radio.weblogs.com/0122027/>

>
> If it is.., what (free) alternatives I have?..
>

http://www.google.com/search?q=open+source+jdbc+connection+pool

Re: DBCP not ready for production server?

[Rosdi Kasim <ro...@epantai.com.my>]

Thanks for the clarification..
Actually I have been using it for our intranet project (2-3 concurrent
user).... and everything seems to work fine..

Only that I dont have the guts (yet) to propose to my boss to throw away our
old Weblogic and migrate to Tomcat for our
external projects.

Perhaps I will do a stress test first on our development server using
Tomcat+DBCP and see how it performs.

Regards,
Rosdi.


----- Original Message ----- 
From: "Danny Angus" <da...@apache.org>
To: "Jakarta Commons Users List" <co...@jakarta.apache.org>
Sent: Friday, July 18, 2003 5:14 PM
Subject: RE: DBCP not ready for production server?


> I think the summary of the issues is fairly accurate, but in my opinion it
> makes too big a deal out of them (but I would say that wouldn't I?).
>
> I think the conclusions in the "bugs" section are unnecessarily harsh and
it
> is by no-means true that no-one will address any of these issues, in fact
> the author himself is at liberty to do so should he wish to.
>
> As the author of a commercial JDBC pool I'd reinforce the message that you
> _can_ avoid the issues stated by using the pool correctly, and in fact
> Tomcat uses JDBC all over the world everyday without Jakarta being
harrassed
> about it.
>
> I'd say that the most important of these issues is the one of failing
> silently, that Double connection use and Resource leakage are a result of
> bad programming by the user (and could perhaps be highlighted by faster
more
> explicit failures), and that reallyClose() should perhaps not even be a
> public method. I am not convinced that this action should be possible
except
> by the pool itself, if there are times when code wants to flag a
connection
> for real-closure I'd prefer to see a mechanism whereby it can be flagged
and
> let the pool handle as it wishes to on normal close(), IMO the user is
> delegating connection management to the pool and cannot expect to also
> directly intervene in the lifecycle.
>
> My advice is to _try_ DBCP and keep the issues discussed in this paper in
> the front of your mind while you use it.
>
> d.
>
> > -----Original Message-----
> > From: Rosdi Kasim [mailto:rosdi@epantai.com.my]
> > Sent: 18 July 2003 07:45
> > To: Jakarta Commons Users List
> > Subject: DBCP not ready for production server?
> >
> >
> > Is this true?
> >
> > http://216.239.57.104/search?q=cache:mX0TKkjHWLMJ:stealthis.athens
>
group.com/presentations/White_Papers/Jakarta_Pooling.doc+dbcp+connection+poo
> l+leak&hl=en&ie=UTF-8
> >
> > If it is.., what (free) alternatives I have?..
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-user-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>

RE: DBCP not ready for production server?

[Danny Angus <da...@apache.org>]

I think the summary of the issues is fairly accurate, but in my opinion it
makes too big a deal out of them (but I would say that wouldn't I?).

I think the conclusions in the "bugs" section are unnecessarily harsh and it
is by no-means true that no-one will address any of these issues, in fact
the author himself is at liberty to do so should he wish to.

As the author of a commercial JDBC pool I'd reinforce the message that you
_can_ avoid the issues stated by using the pool correctly, and in fact
Tomcat uses JDBC all over the world everyday without Jakarta being harrassed
about it.

I'd say that the most important of these issues is the one of failing
silently, that Double connection use and Resource leakage are a result of
bad programming by the user (and could perhaps be highlighted by faster more
explicit failures), and that reallyClose() should perhaps not even be a
public method. I am not convinced that this action should be possible except
by the pool itself, if there are times when code wants to flag a connection
for real-closure I'd prefer to see a mechanism whereby it can be flagged and
let the pool handle as it wishes to on normal close(), IMO the user is
delegating connection management to the pool and cannot expect to also
directly intervene in the lifecycle.

My advice is to _try_ DBCP and keep the issues discussed in this paper in
the front of your mind while you use it.

d.

> -----Original Message-----
> From: Rosdi Kasim [mailto:rosdi@epantai.com.my]
> Sent: 18 July 2003 07:45
> To: Jakarta Commons Users List
> Subject: DBCP not ready for production server?
>
>
> Is this true?
>
> http://216.239.57.104/search?q=cache:mX0TKkjHWLMJ:stealthis.athens
group.com/presentations/White_Papers/Jakarta_Pooling.doc+dbcp+connection+poo
l+leak&hl=en&ie=UTF-8
>
> If it is.., what (free) alternatives I have?..
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>