[ 
https://issues.apache.org/jira/browse/POOL-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13085158#comment-13085158
 ] 

Rob Eamon commented on POOL-99:
-------------------------------

The DB case was just an example. You're right that the testOnBorrow could do a 
simple validation query. But why do a validation query when one can know up 
front that the pool object is stale?

IMO, there is no reason for the pool to not at least provide the information 
for when the object went idle so that the pool client can determine for itself 
whether or not the object is valid. The pool client developer can make the 
determination about what's expensive and what isn't.

I understand the view that the idle notion of the pool is intended to avoid 
holding on to objects that are unlikely to be used, or at least not used for 
considerable time.

But "unlikely to be used" is awfully close to "shouldn't be used." Given that 
the test is the same, why not leverage the idle time facilities?

> Test  for idle time exceeded in borrowObject
> --------------------------------------------
>
>                 Key: POOL-99
>                 URL: https://issues.apache.org/jira/browse/POOL-99
>             Project: Commons Pool
>          Issue Type: Improvement
>    Affects Versions: 1.3
>            Reporter: Rob Eamon
>            Priority: Minor
>             Fix For: 2.0
>
>
> For GenericObjectPool, the evictor thread performs a calculation to determine 
> if an idle object as "expired." If it has, the object is destroyed.
> Would like borrowObject to perform the same test and destroy behavior.
> I explored using the testOnBorrow facility but the time that the object went 
> idle is not available. Only the pool has access to the ObjectTimestampPair 
> object that is used to record the time that the object was placed in the 
> pool. I explored placing a timestamp in the pooled object and can do that but 
> it would seem better if the pool managed that test itself.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to