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. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
