commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz (JIRA)" <j...@apache.org>
Subject [jira] Commented: (POOL-165) idle object eviction-too coarse grained locking
Date Fri, 16 Apr 2010 17:28:25 GMT

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

Phil Steitz commented on POOL-165:
----------------------------------

This is actually a documentation bug.  As of pool 1.5, the idle object evictor does not lock
the pool throughout its execution.  Most importantly, factory methods are no longer performed
in synchronized scope.  The warning above should be reworded; but there is no need to implement
finer-grained locking, IMO.   Thanks for pointing out the error in the javadoc.

> 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.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message