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: Should network client and engine be *required* to match SQL States? (was Re: [jira] Commented: (DERBY-1149) 'jdbc40/StatementTest.junit' fails under DerbyNetClient)
Date Tue, 28 Mar 2006 00:38:40 GMT
Thanks, that seems reasonable to me, and is the approach I will follow 
unless I hear some good arguments to the contrary.

David

Rick Hillegas wrote:
> Hi David,
> 
> I agree that this is a good goal. However, I wouldn't say that this is 
> the most important discrepancy distinguishing our clients. It seems to 
> me that client-convergence, including SQLState agreement, is a big 
> project, requiring a systematic plan. I say, keep closing the gap on an 
> ad-hoc basis until someone volunteers for the big, systematic project.
> 
> Just my two cents.
> 
> Regards,
> -Rick
> 
> David W. Van Couvering wrote:
> 
>> I thought I'd change the subject because of something I brought up at 
>> the end of this message.  Take a look, I think it's something worth 
>> discovering, and potentially bringing up for a vote.
>>
>> David
>>
>> David W. Van Couvering wrote:
>>
>>> Thanks for catching this, Kristian.  As I go through messages on the 
>>> client, I try to find a matching message that already exists for the 
>>> embedded code.  I have not tried to actually look at the "same" code 
>>> on the embedded side, as it's really hard to tell what the "same" 
>>> code is, and where it is.
>>>
>>> I think the message "Invalid transaction state" is very vague, and in 
>>> this way is very general and reusable.  I have heard Dan state that 
>>> general and reusable is better than specific and not reusable.  I am 
>>> personally having trouble knowing how to best balance a 
>>> comprehensible message with one that is too specific.
>>>
>>> In this case, however, I think "Invalid transaction state" is so 
>>> vague as to be pretty much unhelpful.  I would vote that we migrate 
>>> CANNOT_CLOSE_ACTIVE_XA_CONNECTION from a client-specific message in 
>>> client/.../loc/clientmessages_en.properties to a reusable message in 
>>> engine/.../loc/messages_en.properties.
>>>
>>> I also think that the standard SQL State of 25000 is incorrectly 
>>> used, here.  This isn't an invalid transaction state.  It's an 
>>> attempt to close a connection with an open transaction.  If anything 
>>> it *might* be a connection exception (08000), but I actually think it 
>>> doesn't apply to either of these, and probably the SQL State, once 
>>> you migrate it, should start with "XJ" - JDBC exceptions.
>>>
>>> I am also realizing that we as a community need to decide if we want 
>>> to ensure that the network client and the engine should always have 
>>> the same SQL States for the same exceptions.  It's laudable, and if 
>>> we catch differences I think we should fix them, but I am not sure if 
>>> it should be *required*, especially for existing code.  It is *very* 
>>> hard to reliably backport this consistency into existing code, as the 
>>> code paths on the two drivers are quite different.  If anyone has any 
>>> ideas about this, it would be much appreciated.
>>>
>>> David
>>>
>>> P.S. I'll start running the jdbc40 test suite as well as derbyall 
>>> prior to checkin of i18n changes.
>>>
>>> Kristian Waagan (JIRA) wrote:
>>>
>>>>     [ 
>>>> http://issues.apache.org/jira/browse/DERBY-1149?page=comments#action_12371754

>>>> ]
>>>> Kristian Waagan commented on DERBY-1149:
>>>> ----------------------------------------
>>>>
>>>> I need a little help on my issue. The following diff is from r388309:
>>>>
>>>> --- 
>>>> /db/derby/code/trunk/java/client/org/apache/derby/client/am/Connection.java
   
>>>> 2006/03/24 00:54:27    388308
>>>> +++ 
>>>> db/derby/code/trunk/java/client/org/apache/derby/client/am/Connection.java
   
>>>> 2006/03/24 00:55:44    388309
>>>> [snip]
>>>>          // The following precondition matches CLI semantics, see 
>>>> SQLDisconnect()
>>>>          if (!autoCommit_ && inUnitOfWork_ && !allowCloseInUOW_())
{
>>>>              throw new SqlException(agent_.logWriter_,
>>>> -                    "java.sql.Connection.close() requested while a 
>>>> transaction is in progress on the connection." +
>>>> -                    "The transaction remains active, and the 
>>>> connection cannot be closed.");
>>>> +                    new MessageId 
>>>> (SQLState.CANNOT_CLOSE_ACTIVE_XA_CONNECTION));                   
>>>>          }
>>>> [snip]
>>>>
>>>> Is this change correct?
>>>> In my test, the SQLState used on the embedded side is
>>>> LANG_INVALID_TRANSACTION_STATE (25000):
>>>> # Transaction states, matches DB2
>>>> 25000=Invalid transaction state.
>>>>
>>>> The way I see it, without much knowledge about this, there are multiple
>>>> possible outcomes:
>>>> 1) The change is invalid, and we start using
>>>> SQLSTATE.LANG_INVALID_TRANSACTION_STATE on the client as well.
>>>> 2) The change is correct, and I change the test to reflect this.
>>>> 3) The change is invalid, and we make 
>>>> SQLSTATE.LANG_INVALID_TRANSACTION_STATE
>>>> more verbose (aka the old message on the client) and start using it 
>>>> on the
>>>> client and update the message text for embedded.
>>>>
>>>> What do you say?
>>>>
>>>>
>>>>
>>>>> '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: Kristian Waagan
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> 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