commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [dbcp] 1.3/1.4 RC1 available for review
Date Thu, 17 Dec 2009 02:15:30 GMT
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.

Phil

> Phil
>> - Jörg
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message