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 Tue, 25 Mar 2003 14:53:51 GMT
Craig wrote:

> But I think we might be using the term "recycle" differently.
> By "recycle", do you mean "if a connection has been setting in the pool
> for a long time and is not allocated to an application, so we can close it
> now"?  

No, thats pool administration. IMO its an implementation detail that should be of no concern
of the user, its existence should only be exposed indirectly through settings such as "test
while idle". Although in practice it helps if you know whats going on. 

> Or, by "recycle", do you mean "if a connection has been allocated to an
> application but not returned for a long time, the pool is allowed to grab
> it back again -- but you want to notify the application first".  The "grab
> it back" behavior is already configurable (and not enabled by default) --
> and it's this functionality that I object to having at all.  If there was
> no "grab it back" we wouldn't have to worry about notifying anyone that it
> was about to happen :-).

This was what actually I meant by recycling, from the POV that the whole pooling pattern is
about re-cycling objects dispensed with by one Object but of use to another (as in trash re-cycling)
to reduce the overhead of creating identical new objects.

Its my opinion that it is beyond the remit of the pool to re-use objects which have not been
positively freed by the Object which was last assigned them. My reasons are that it builds
in the potential for unpredictable failures, and only benefits broken code.

So I think we agree... 

> If we're talking about the second use of "recycled" above, IMHO, I think
> adding support for recovering abandoned connections at all was a mistake.
> Doing anything to make it work "better" (knowing all the while that it
> cannot be made "perfect") simply perpetuates the mistake.  I'd much rather
> see this whole area of functionality deprecated, rather than continuing to
> mislead people into believing that its OK to depend on something that
> cannot ever work reliably 100% of the time.

I'd agree with that too.

What has now occured to me is that this philosophy also delegates the responsibility to the
connection consumer for ensuring that refrences, direct or indirect, to the connection are
never used once the connection has been passed back to the pool. Otherwise this is another
area where confusing behaviour could result from subtle bad code. 
The notion expressed by someone else of creating new wrappers for each request delegating
to truly pooled connections, with the wrappers discarded when the connection is returned to
the pool would prevent refrences to wrappers being used to access the real pooled resources.
On the other hand this safety might negate too much of the performance boost pooling provides.


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

View raw message