commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <p...@steitz.com>
Subject Re: [POOL] you can return your object several times?
Date Thu, 05 Jun 2008 01:42:37 GMT
sebb wrote:
> On 04/06/2008, Mark Thomas <markt@apache.org> wrote:
>   
>>  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.
>>     
>
> Nor can I, and the code should not allow that to happen.
> It should either treat the second call as a noop, or throw an exception.
>
> But allowing the application to returnObject() more than once may
> perhaps be useful, as in the close() analogy.
>
>   
>>  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...
>>
>>     
The practical problem here is that you would need to fully search the 
pool on each returnObject.  This could cause performance problems and 
would be tricky to do safely.  Also, I need some convincing that it is a 
good idea for the pool to make any commitments regarding client 
references to objects that have been returned - i.e., allowing clients 
to continue to hold and meaningfully use these references (which 
returning them twice basically gets into).  

I assume also that reference equality, not equals would be used to 
compare; otherwise some legitimate use cases could break.

If this behavior is really important to client applications, it is 
probably better on the client side to wrap the pooled objects in an 
adaptor that makes "close" or "return" idempotent, which is what DBCP 
does (in trunk repeated close is now allowed). 

Phil


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


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


Mime
View raw message