[
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.