Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Mon, 27 Mar 2006 15:28:34 -0800
From: Rick Hillegas <Richard.Hillegas@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)
In-reply-to: <4428461B.8020709@sun.com>
To: derby-dev@db.apache.org
Message-id: <44287522.7040101@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
References: <551051991.1143218359209.JavaMail.jira@ajax>
 <44282798.8030908@sun.com> <4428461B.8020709@sun.com>

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