[
https://issues.apache.org/jira/browse/POOL-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandy McArthur closed POOL-101.
-------------------------------
Resolution: Won't Fix
Assignee: Sandy McArthur
I'm not convinced this is a worthwhile issue.
First, any subclasses of BaseObjectPool can do whatever synchronization they
need to do for correct behavior. Different pools have different needs.
Second, the alternative is to synchronize all access to the closed field. That
will have a negative performance impact for all calls to assertOpen which is
rather frequent. Since the subclass is responsible for correct, thread-safe
behavior, there is little reason for BOP to assume that responsibility.
Closing this for now. If you can show me it's a problem in a larger context
I'll reconsider.
> BaseObjectPool does not provide atomicity for closed-Operations
> ---------------------------------------------------------------
>
> Key: POOL-101
> URL: https://issues.apache.org/jira/browse/POOL-101
> Project: Commons Pool
> Issue Type: Bug
> Affects Versions: 1.3
> Reporter: Marcos Sanz
> Assigned To: Sandy McArthur
> Priority: Minor
>
> Though the "closed" field has been declared volatile in the abstract class
> BaseObjectPool, atomic operations are not guaranteed. Thus, the code
> public void close() throws Exception {
> assertOpen();
> closed = true;
> }
> is broken. I've marked the issue as minor priority, since the semantic
> consequences are not very far-reaching (in the worst case, the pool can be
> closed twice), but the error could be potentiated if exploited further.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
