You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Marcos Sanz (JIRA)" <ji...@apache.org> on 2007/04/13 15:22:15 UTC
[jira] Created: (POOL-101) BaseObjectPool does not provide
atomicity for closed-Operations
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
Priority: Minor
Though the "closed" field has been declared volatile in the abstract class BaseObjectPool, atomic operations are not guaranteed. Thus, the code
--
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Updated: (POOL-101) BaseObjectPool does not provide
atomicity for closed-Operations
Posted by "Marcos Sanz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/POOL-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marcos Sanz updated POOL-101:
-----------------------------
Description:
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.
was:
Though the "closed" field has been declared volatile in the abstract class BaseObjectPool, atomic operations are not guaranteed. Thus, the code
> 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
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[jira] Closed: (POOL-101) BaseObjectPool does not provide atomicity
for closed-Operations
Posted by "Sandy McArthur (JIRA)" <ji...@apache.org>.
[ 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org