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