db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-1149) 'jdbc40/StatementTest.junit' fails under DerbyNetClient
Date Wed, 29 Mar 2006 17:00:30 GMT

Kristian Waagan (JIRA) wrote:
>     [ http://issues.apache.org/jira/browse/DERBY-1149?page=comments#action_12372240 ]

> 
> Kristian Waagan commented on DERBY-1149:
> ----------------------------------------
> 
> This patch will (and does) fail, due to the way SQLStates are compared. I will brush
up the patch, only changing things in StatementTest, were this testing was not good enough
(all tests, not only the one that failed here).
>


The name SQLState.java is actually misleading.  These are really message 
ids being defined, *not* SQL States.

The SQLStates are derived from the message ids as the first five 
characters of the message id.

See the method 
org.apache.derby.shared.common.error.ExceptionUtil.getSQLStateFromIdentifier().

I was also misled by this.  We shouldn't use SQLState constants when 
checking the SQL State.
We have to use the actual five-character SQLState.

I'l take a look at your change and see if that does what we need to do.

You know, I must be running the jdbc40 tests wrong, because it came out 
with a success when it obviously should have been a failure.  I will 
look into this.

> David, can you explain why you have set the SQLState to "25000.S.1", and not to "25001"?
> Is the former an SQLState encoding exception category, as described in the class comments
for SQLState.java?

Yes, it should be 25001, I somehow missed that in our original exchange; 
rereading your email (http://tinyurl.com/l4xwr) you were referring to 
25001, not 25000.

The former was when I was assuming that we had two messages for the same 
SQL State (25000), in which case they are distinguished with a suffix 
number.  Due to the way exception severity is determined (using a 
default or by using the ".N" suffix after the first five characters), 
you have to append the severity and then the suffix number, e.g. 25000.S.1.

See 
http://www.nabble.com/Multiple-causes-for-same-SQL-State-t991637.html#a2568667

> 
> Do we want to use the invalid trasaction state also for XA connections? I see it has
been added in EmbedXAConnection. Is the CANNOT_CLOSE_ACTIVE_XA_CONNECTION wrong/deprecated
for XA connections?

I think that we want to use the invalid transaction state (25001 - 
active SQL-transaction) for XA connections as well.  Is there a reason 
they should be treated differently?

Thanks for looking at this.

David
> 
> Besides from these questions, I think the patch is good to go, but I would appreciate
if it was held back until the questions above were answered and I had the time to add some
fixes to StatementTest.
> 
> 
> 
> 
>>'jdbc40/StatementTest.junit' fails under DerbyNetClient
>>-------------------------------------------------------
>>
>>         Key: DERBY-1149
>>         URL: http://issues.apache.org/jira/browse/DERBY-1149
>>     Project: Derby
>>        Type: Test
>>  Components: Regression Test Failure, Test
>>    Versions: 10.2.0.0
>> Environment: JDK 1.6 (b76 used, believed to apply to all)
>>    Reporter: Kristian Waagan
>>    Assignee: David Van Couvering
>> Attachments: DERBY-1149-StatementTestFaiure.diff
>>
>>One of the tests in jdbc40/StatementTest.junit fails with the following message:
>>"Attempt to shutdown framework: DerbyNetClient
>>0 add
>>
>>>....F.
>>>There was 1 failure:
>>>1) testIsClosedWhenClosingConnectionInInvalidState(org.apache.derbyTesting.functionTests.tests.jdbc4.StatementTest)junit.framework.ComparisonFailure:
Unexpected exception thrown: Cannot close a connection while a global transaction is still
active. expected:<java.sql.Connection.close() requested while a transaction is in progress
on the connection.The transaction remains active, and the connection cannot be closed...>
but was:<Cannot close a connection while a global transaction is still active...>
>>>FAILURES!!!
>>>Tests run: 5,  Failures: 1,  Errors: 0
>>
>>Test Failed.
>>*** End:   StatementTest jdk1.6.0-beta2 DerbyNetClient 2006-03-24 12:53:22 ***"
>>The reason is that the exception message text has been changed. This comparison is
only done when running DerbyNetClient, because SQLState was not implemented there.
>>The checkin that caused the error:
>>"Author: davidvc
>>Date: Thu Mar 23 16:55:44 2006
>>New Revision: 388309
>>URL: http://svn.apache.org/viewcvs?rev=388309&view=rev
>>Log:
>>DERBY-839 (Partial).  Internationalize Connection.java.  Also upgraded
>>the "i18n lint" test to be a little more intelligent, and to not exit
>>on the first failure.
>>Passes derbynetclientmats.  All changes are client-specific so derbyall
>>was not run."
>>A
> 
> 

Mime
View raw message