commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "yangxuesong (JIRA)" <>
Subject [jira] [Commented] (POOL-263) GenericObjectPool close and returnObject is not synchronized
Date Thu, 24 Apr 2014 01:44:15 GMT


yangxuesong commented on POOL-263:

"It is theoretically possible however that the steps in the middle above happen between the
time that idleObjects.addLast is invoked and when it acquires the lock."
from the above line, I think you are agree with "there is a very small chance of orphan instance"
(Am I right?)

"A test case illustrating that this can actually happen would be most appreciated. Also, any
suggestions on how to ensure that it can't happen without adding material overhead to either
of the methods involved"
the test case is not easy to produce, since I can NOT control the execution order of each
thread. What I do is theoretically analyze.
Besides, if we want to ensure that can't happen, I think an material overhead is unavoidable.
such as synchronize returnObject method with the closeLock object which is used in close method.

Thanks for your quick response!

> GenericObjectPool close and returnObject is not synchronized
> ------------------------------------------------------------
>                 Key: POOL-263
>                 URL:
>             Project: Commons Pool
>          Issue Type: Bug
>    Affects Versions: 2.2
>         Environment: ALL
>            Reporter: yangxuesong
> the javadoc on GenericObjectPool#close() says:
> "Closes the pool. Once the pool is closed, borrowObject() will fail with IllegalStateException,
but returnObject(Object) and invalidateObject(Object) will continue to work, with returned
objects destroyed on return.
> Destroys idle instances in the pool by invoking clear()."
> Thread1: pool.close()
> Thread2: pool.returnObject()
> since close and returnObject is not synchronized, there is a small chance that an returned
object is not destoryed after the pool is closed

This message was sent by Atlassian JIRA

View raw message