db-derby-dev mailing list archives

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

> 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 havn't looked at the ExceptionUtil method, but I guess it is another
substring(0,5) - as the one in StandardException.

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

Well, it does and it doesn't. It trucates the incoming string, but since
I have used a disallowed comparison (referring SQLState in the test),
the patch must be modified again.

> 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.

Nothing magic, just remember to use JDK 1.6 when running (put it first
in path or something). You should see the JVM version from the output.
Besides from that, nothing special is required to run the suite.

>> 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 

Okay, I see. I was confused by the comment in SQLState, talking about
chars 8 and 9 begin some kind of exception category. Couldn't get it to
match with your naming. I have also seen a few identifiers using 3
digits at the end, so that the total length gets up to 11.

>> 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?

Not that I know of, I was just asking :) I guess the XA message is a
Derby specific thing/leftover.

I posted an updated patch on Jira, changing the identifer and the
StatementTest SQLState comparions. I have no more questions to the patch.


> 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:
>>> 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

View raw message