You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Phil Steitz (JIRA)" <ji...@apache.org> on 2011/04/29 00:16:04 UTC
[jira] [Created] (DBCP-358) Equals implementations in DelegatingXxx
classes are not symmetric
Equals implementations in DelegatingXxx classes are not symmetric
-----------------------------------------------------------------
Key: DBCP-358
URL: https://issues.apache.org/jira/browse/DBCP-358
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 1.4, 1.3, 1.2.2, 1.2
Reporter: Phil Steitz
Fix For: 1.3.1, 1.4.1
For reasons unclear to me, DelegatingConnection, DelegatingStatement, PoolGuardConnectionWrappers and other DBCP classes implement equals so that the wrapping class is considered equal to its innermost delegate JDBC object. This makes equals asymmetric when applied to a wrapper and its wrapped JDBC object - equals(wrapper, delegate) returns true, but equals(delegate, wrapper) will in general return false.
I am pretty sure that DBCP itself does not rely on this bugged behavior, so I am inclined to fix it, making equals an equivalence relation on wrapper instances, with two considered equal iff their innermost delegates are equal. I can't imagine use cases where the bugged behavior is required. Can anyone else?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBCP-358) Equals implementations in
DelegatingXxx classes are not symmetric
Posted by "Joerg Schaible (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13027957#comment-13027957 ]
Joerg Schaible commented on DBCP-358:
-------------------------------------
This behavior is unfortunately used in the PoolableManagedConnection w/ TransactionRegistry. When a new connection is created in the pool, the unwrapped connection is registered (and used as key in the internal WeakHashMap). Later on the wrapped connection is used to unregister again (or to lookup the XAResource as done in org.apache.commons.dbcp.managed.TestBasicManagedDataSource.testReallyClose()). As workaround it is possible to wrap the registered connection if it is not wrapped yet:
{noformat}
Index: src/java/org/apache/commons/dbcp/managed/TransactionRegistry.java
===================================================================
--- src/java/org/apache/commons/dbcp/managed/TransactionRegistry.java (revision 1098813)
+++ src/java/org/apache/commons/dbcp/managed/TransactionRegistry.java (working copy)
@@ -28,7 +28,9 @@
import javax.transaction.TransactionManager;
import javax.transaction.xa.XAResource;
+import org.apache.commons.dbcp.DelegatingConnection;
+
/**
* TransactionRegistry tracks Connections and XAResources in a transacted environment for a single XAConnectionFactory.
* </p>
@@ -62,7 +64,10 @@
public synchronized void registerConnection(Connection connection, XAResource xaResource) {
if (connection == null) throw new NullPointerException("connection is null");
if (xaResource == null) throw new NullPointerException("xaResource is null");
- xaResources.put(connection, xaResource);
+ Connection key = connection instanceof DelegatingConnection
+ ? connection
+ : new DelegatingConnection(connection);
+ xaResources.put(key, xaResource);
}
/**
{noformat}
This approach will also solve DBCP-356 (another workaround is to use a HasMap instead of a WeakHashMap for the XAResources).
> Equals implementations in DelegatingXxx classes are not symmetric
> -----------------------------------------------------------------
>
> Key: DBCP-358
> URL: https://issues.apache.org/jira/browse/DBCP-358
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.2, 1.2.2, 1.3, 1.4
> Reporter: Phil Steitz
> Fix For: 1.3.1, 1.4.1
>
>
> For reasons unclear to me, DelegatingConnection, DelegatingStatement, PoolGuardConnectionWrappers and other DBCP classes implement equals so that the wrapping class is considered equal to its innermost delegate JDBC object. This makes equals asymmetric when applied to a wrapper and its wrapped JDBC object - wrapper.equals(delegate) returns true, but delegate.equals(wrapper) will in general return false.
> I am pretty sure that DBCP itself does not rely on this bugged behavior, so I am inclined to fix it, making equals an equivalence relation on wrapper instances, with two considered equal iff their innermost delegates are equal. I can't imagine use cases where the bugged behavior is required. Can anyone else?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DBCP-358) Equals implementations in DelegatingXxx
classes are not symmetric
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Phil Steitz updated DBCP-358:
-----------------------------
Description:
For reasons unclear to me, DelegatingConnection, DelegatingStatement, PoolGuardConnectionWrappers and other DBCP classes implement equals so that the wrapping class is considered equal to its innermost delegate JDBC object. This makes equals asymmetric when applied to a wrapper and its wrapped JDBC object - wrapper.equals(delegate) returns true, but delegate.equals(wrapper) will in general return false.
I am pretty sure that DBCP itself does not rely on this bugged behavior, so I am inclined to fix it, making equals an equivalence relation on wrapper instances, with two considered equal iff their innermost delegates are equal. I can't imagine use cases where the bugged behavior is required. Can anyone else?
was:
For reasons unclear to me, DelegatingConnection, DelegatingStatement, PoolGuardConnectionWrappers and other DBCP classes implement equals so that the wrapping class is considered equal to its innermost delegate JDBC object. This makes equals asymmetric when applied to a wrapper and its wrapped JDBC object - equals(wrapper, delegate) returns true, but equals(delegate, wrapper) will in general return false.
I am pretty sure that DBCP itself does not rely on this bugged behavior, so I am inclined to fix it, making equals an equivalence relation on wrapper instances, with two considered equal iff their innermost delegates are equal. I can't imagine use cases where the bugged behavior is required. Can anyone else?
> Equals implementations in DelegatingXxx classes are not symmetric
> -----------------------------------------------------------------
>
> Key: DBCP-358
> URL: https://issues.apache.org/jira/browse/DBCP-358
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.2, 1.2.2, 1.3, 1.4
> Reporter: Phil Steitz
> Fix For: 1.3.1, 1.4.1
>
>
> For reasons unclear to me, DelegatingConnection, DelegatingStatement, PoolGuardConnectionWrappers and other DBCP classes implement equals so that the wrapping class is considered equal to its innermost delegate JDBC object. This makes equals asymmetric when applied to a wrapper and its wrapped JDBC object - wrapper.equals(delegate) returns true, but delegate.equals(wrapper) will in general return false.
> I am pretty sure that DBCP itself does not rely on this bugged behavior, so I am inclined to fix it, making equals an equivalence relation on wrapper instances, with two considered equal iff their innermost delegates are equal. I can't imagine use cases where the bugged behavior is required. Can anyone else?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBCP-358) Equals implementations in
DelegatingXxx classes are not symmetric
Posted by "Joerg Schaible (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DBCP-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13027967#comment-13027967 ]
Joerg Schaible commented on DBCP-358:
-------------------------------------
Thinking about it ... if I create a *temporary* connection instance and use it as key in a WeakHashMap, it does not make too much sense either. OTOH, if I use an unwrapped connection as key that is also part of the WeakHashMap's value (the xaResource), the WeakHashMap is also useless. So, what do we try to solve with the WeakHashMap for the XAResources here?
> Equals implementations in DelegatingXxx classes are not symmetric
> -----------------------------------------------------------------
>
> Key: DBCP-358
> URL: https://issues.apache.org/jira/browse/DBCP-358
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.2, 1.2.2, 1.3, 1.4
> Reporter: Phil Steitz
> Fix For: 1.3.1, 1.4.1
>
>
> For reasons unclear to me, DelegatingConnection, DelegatingStatement, PoolGuardConnectionWrappers and other DBCP classes implement equals so that the wrapping class is considered equal to its innermost delegate JDBC object. This makes equals asymmetric when applied to a wrapper and its wrapped JDBC object - wrapper.equals(delegate) returns true, but delegate.equals(wrapper) will in general return false.
> I am pretty sure that DBCP itself does not rely on this bugged behavior, so I am inclined to fix it, making equals an equivalence relation on wrapper instances, with two considered equal iff their innermost delegates are equal. I can't imagine use cases where the bugged behavior is required. Can anyone else?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira