commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: [POOL] you can return your object several times?
Date Wed, 04 Jun 2008 08:18:37 GMT

sebb wrote:
> On 03/06/2008, Mark Thomas <markt@apache.org> wrote:
>>  kpetrov wrote:
>>
>>>
>>>
>>> Mark Thomas-18 wrote:
>>>
>>>> kpetrov wrote:
>>>>
>>>>> I tested a simple scenario where I return the same object several
>> times:
>>>> Which version of pool are you using?
>>>>
>>>>
>>>>
>>> 1.4. Actually, just checked the source code...seems like this is done by
>>> design... was surprised though.
>>>
> 
> So long as it is documented, it seems reasonable to me.
I may not be understanding the code correctly but it looks like only 
GenericObjectPool has a warning on returnObject() but other implementations 
have the same contract but no warning. A patch that updated the JavaDocs 
wouldn't hurt.

> For example, some close() methods can be called multiple times; only
> the first close() needs to do anything, later calls to close() are
> ignored. This can be useful in cleanup code.
I should look at the code some more. I am wondering what happens when 
threadA calls close() (which in turn calls returnObject()) , threadB calls 
borrowObject() and gets the object just returned by threadA and whilst 
threadB is using the object threadA calls close() again.

>>  I haven't looked at the code in a while so I don't know how easy it would
>> be to patch this. If you were able to suggest a patch I am sure it would be
>> welcomed (create a JIRA issue and attach it there).
> 
> I don't think the behaviour should be changed unless it is clearly not intended.
> And even then, unless it causes a problem, why risk breaking
> applications that rely on it?
I can't think of any use cases where having the same object in the pool 
more than once is anything other than a bug. I would be interested in any 
use case you have that relies on this behaviour.

The complexity of the code necessary to enforce the contract stated in the 
Javadocs would have to be weighed against the benefits of explicitly 
enforcing the contract. I can see some benefit in doing this but until 
there is an actual patch to consider...

Mark


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


Mime
View raw message