[ 
https://issues.apache.org/jira/browse/POOL-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Phil Steitz resolved POOL-165.
------------------------------

    Resolution: Fixed

Javadoc updated in r937879.

> idle object eviction-too coarse grained locking
> -----------------------------------------------
>
>                 Key: POOL-165
>                 URL: https://issues.apache.org/jira/browse/POOL-165
>             Project: Commons Pool
>          Issue Type: New Feature
>            Reporter: Mircea Markus
>             Fix For: 1.5.5
>
>
> From GenericKeyedObjectPoolFactory's javadoc:
> "Optionally, one may configure the pool to examine and possibly evict objects 
> as they sit idle in the pool and to ensure that a minimum number of idle 
> objects is maintained for each key. This is performed by an "idle object 
> eviction" thread, which runs asynchronously. Caution should be used when 
> configuring this optional feature. Eviction runs require an exclusive 
> synchronization lock on the pool, so if they run too frequently and / or 
> incur excessive latency when creating, destroying or validating object 
> instances, performance issues may result. The idle object eviction thread may 
> be configured using the following attributes.."
> This can be improved im the following manner:
> - use an lock per object rather than per pool. Whenever borrowing an object  
> acquire a write lock for the time object is borrowed
> - the "idle object eviction" will check if the object is locked and if so 
> ignore it - this is  a best effort approach that should satisfy most of the 
> scenarios. Otherwise acquire a lock on it, and it won't be available for 
> clients.
> Glad to help on this one!
>   

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to