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. d. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
