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