commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Angus" <>
Subject RE: [DBCP] Please let us start to improve the connection pool
Date Mon, 24 Mar 2003 22:28:29 GMT

> IMHO, any application that depends on the connection pool for recovering
> abandoned connections (whether or not it recycles them) is broken.  Far
> better is to focus your energy on avoiding all the cases where you grab a
> connection from the pool but fail to return it for some reason.
> One simple way to do this is to encapsulate your JDBC-using code in a
> try/catch/finally block, something like this:

I haven't used DBCP for anthing yet, though we're proposing to use it for James in place of
our homespun pool.

However from what I understand of this discussion there are two things going on here;

Thing one, I agree with you, code failing to return connections to the pool should lead to
failure, and the sooner this can be done the better for identifying such broken code.

Thing two, DBCP will apparently make a value judgement about an assigned connection, and is
capable of recycling it with no notification to the code which has checked it out. 

In my opinion thing two is wrong or incomplete as it creates a situation where potential failure
is built in, difficult to reproduce and difficult identify the cause of.

In the case of JDBC connection pooling may be reasonable to want to keep a connection even
when it is idle, because connections can aquire state which is expensive to reproduce. Is
it not, then, unresonable to allow the pool to silently and forcably recycle apparently idle
but valuable connections?

My solution would either be to make it possible to turn off the forcable recycling of connections,
or to make the pool capable of notifying code that its connection has been recycled.

Is that reasonable?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message