Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <551051991.1143218359209.JavaMail.jira@ajax>
Date: Fri, 24 Mar 2006 16:39:19 +0000 (GMT)
From: "Kristian Waagan (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-1149) 'jdbc40/StatementTest.junit' fails
 under DerbyNetClient
In-Reply-To: <1002121520.1143202220148.JavaMail.jira@ajax>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ 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

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira