commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Bollinger (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (POOL-125) Insufficient control over concurrent access to pooled objects by Evictor, client threads
Date Thu, 16 Apr 2009 22:38:14 GMT

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

John Bollinger edited comment on POOL-125 at 4/16/09 3:37 PM:
--------------------------------------------------------------

I've been looking at this in the version 1.x source, and I'm not sure I see the problem. 
The Evicter operates by invoking the synchronized GenericObjectPool.evict() method, which
touches only objects currently idle in the pool (_pool).  None of borrowObject(), returnObject(),
and invalidateObject() access the pool without synchronization, and none of them invoke factory
methods on idle pooled objects.  The only opportunities I see for factory methods to be concurrently
invoked on the same object are

- if a client thread returns or invalidates an object that is already idle in the pool then
that thread and the Evicter thread might concurrently invoke factory methods on it
- if two client threads attempt to return / invalidate the same object at the same time then
those threads might concurrently invoke factory methods on it
- (or if the client holds references to the factory and an idle pooled object, and directly
passes the object to a factory method while the Evicter is running)

Those scenarios appear to arise from client errors, and they are likely to cause problems
even if the concurrency can be prevented.  (For example, it may be a problem to invoke destroyObject()
twice *sequentially* with the same argument.)  What am I missing here?

      was (Author: jcbollinger):
    I've been looking at this in the version 1.x source, and I'm not sure I see the problem.
 The Evicter operates by invoking the synchronized GenericObjectPool.evict() method, which
touches only objects currently idle in the pool (_pool).  None of borrowObject(), returnObject(),
and invalidateObject() access the pool without synchronization.  The only opportunities I
see for factory methods to be concurrently invoked on the same object are

- if a client thread returns or invalidates an object that is already idle in the pool then
that thread and the Evicter thread might concurrently invoke factory methods on it
- if two client threads attempt to return / invalidate the same object at the same time then
those threads might concurrently invoke factory methods on it
- (or if the client holds references to the factory and an idle pooled object, and directly
passes the object to a factory method while the Evicter is running)

Those scenarios appear to arise from client errors, and they are likely to cause problems
even if the concurrency can be prevented.  (For example, it may be a problem to invoke destroyObject()
twice *sequentially* with the same argument.)  What am I missing here?
  
> Insufficient control over concurrent access to pooled objects by Evictor, client threads
> ----------------------------------------------------------------------------------------
>
>                 Key: POOL-125
>                 URL: https://issues.apache.org/jira/browse/POOL-125
>             Project: Commons Pool
>          Issue Type: Bug
>    Affects Versions: 1.2, 1.4
>            Reporter: Phil Steitz
>             Fix For: 1.5
>
>
> In pool 1.2, 1.4, borrowObject, returnObject, invalidateObject are not fully synchronized.
 This creates the potential for race conditions vis a vis the Evictor and/or client object
lock contention.  Factory methods on pooled objects should not be allowed to be invoked concurrently
by client threads and the Evictor.

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


Mime
View raw message