Jörg Schaible wrote: > Phil Steitz wrote: > >> Phil Steitz wrote: >>> Jörg Schaible wrote: >>>> Jörg Schaible wrote: >>>> >>>>> Jörg Schaible wrote: >>>>> >>>>>> Hi Phil, >>>>>> >>>>>> Phil Steitz wrote: >>>>>> >>>>>> [snip] >>>>>> >>>>>>>>> 1.4 (JDBC 4) version: >>>>>>>>> http://people.apache.org/~psteitz/dbcp-1.4-rc1 >>>>>>>>> http://people.apache.org/~psteitz/dbcp-1.4-rc1/site >>>>>>>>> http://people.apache.org/~psteitz/dbcp-1.4-rc1/maven >>>>>>>>> > http://svn.apache.org/repos/asf/commons/proper/dbcp/tags/DBCP_1_4_RC1/ >>>>>>>> Builds from source and runs tests with IcedTea6 1.6.2, Sun JDK 1.6 >>>>>>>> and Sun JDK 1.7.0.0.alpha69 (add to README.txt ?!?). However it >>>>>>>> fails with IBM 1.6.0.6: >>>>>>>> >>>>>>>> ========================== %< ================================ >>>>>>>> > ------------------------------------------------------------------------------- >>>>>>>> Test set: org.apache.commons.dbcp.managed.TestBasicManagedDataSource >>>>>>>> > ------------------------------------------------------------------------------- >>>>>>>> Tests run: 46, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: >>>>>>>> 3.398 sec <<< FAILURE! >>>>>>>> > testReallyClose(org.apache.commons.dbcp.managed.TestBasicManagedDataSource) >>>>>>>> Time elapsed: 0.066 sec <<< FAILURE! >>>>>>>> junit.framework.AssertionFailedError: Expecting SQLException - >>>>>>>> XAResources orphaned >>>>>>>> at junit.framework.Assert.fail(Assert.java:47) >>>>>>>> at >>>>>>>> > org.apache.commons.dbcp.managed.TestBasicManagedDataSource.testReallyClose(TestBasicManagedDataSource.java:72) >>>>>>> I could use some help debugging this one. I do not have the JDK to >>>>>>> test with and the failure makes no sense to me. Does it happen >>>>>>> every time? >>>>>> It seems it was caused by a difference in the WeakReference >>>>>> implementation. The DelegactingConnection returned the same hashCode >>>>>> than the inner connection. However, both instances were kept in the >>>>>> registry in xaReference (a WeakMap). >>> Need to figure out why that is happening. This could be a test bug. >>> The connection should only be added once to the registry. >>> >>> After using a distinguishable hashCode, the >>>>>> test succeeds also with IBM JDK. >>>>>> >>>>>> Additionally I dropped the JDK 1.4 deps from the POM. >>> That is OK for the trunk POM. Thanks. >>>>>> I'll look into DBCP 1.3 ASAP - it got too late now ;-) >>>>> Guess it was really too late yesterday. While >>>>> TestBasicManagedDataSource works now, my change borked the >>>>> TestManagedDataSourceInTx tests (interestingly 33 with Sun JDK, but >>>>> only 28 with IBM). Basically my change broke the contract with hashCode >>>>> that should be the same for "equal" objects. >>>>> >>>>> Question is now, what to do. If we revert the change, the IBM JDK is >>>>> broken and it fails to release the transactions. Otherwise we have to >>>>> change additionally the equals method, so that a DelegatingConnection >>>>> is not equal to the wrapped Connection. However, this may case even >>>>> more hick-ups. >>>> I've reverted the hashCode change for now that brings back the IBM JDK >>>> problem. :-/ >>> Thanks, Jorg. I think changing equals is not a good idea. Thanks >>> again for your help. >>> >> This is a test bug. The test is manually registering the connection >> after the LocalXAConnectionFactory has already done it. Fixing >> now. This should eliminate the problem. > > The funny thing is that on Sun JDK registering the ManagedConnection itself > will update the entry in the WeakHashMap of the delegated connection. On IBM > JDK a new entry is created in the map. Later on is the ManagedConnection > removed, but the lookup will now return the delegated connection (may be > because of equality of the connection and its hash code when it is used as > key.
I don't know why the JDK behavior is different, but you have it right - the test code was registering the ManagedConnection returned by the ManagedDataSource whereas the LocalXAConnectionFactory registers the DelegatingConnection that the ManagedConnection wraps. These are equal. Phil > - Jörg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org