Re: [jira] Commented: (DERBY-1149) 'jdbc40/StatementTest.junit' fails under DerbyNetClient
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=388309view=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
Re: [jira] Commented: (DERBY-1149) 'jdbc40/StatementTest.junit' fails under DerbyNetClient
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. -- Kristian 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
Re: [jira] Commented: (DERBY-1149) 'jdbc40/StatementTest.junit' fails under DerbyNetClient
David W. Van Couvering wrote: Hi, Kristian, thanks for your research on this! I didn't know there was more to be said on what SQL States should be used when. It's a little daunting -- every time I change a SQL State in the client I have to peruse this massive tome. Anyway, I would probably use 25001, which is currently not in use. And IMHO we should fix the embedded client to use this more descriptive message. I suppose I should fix this since it was my changes that introduced the regression. Thanks for taking care of it David :) Fixing the test itself should be easy-going. I'll have a look at the patch when it is ready. -- Kristian David Kristian Waagan wrote: 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'm a bit confused. The SQL spec (2003) seem to think that closing a connection with an active transaction is to be considered an invalid transaction state. INVALID_TRANSACTION_STATE_NO_SUBCLASS = 25000. INVALID_TRANSACTION_STATE_ACTIVE_SQL_TRANSACTION = 25001. There are more subclasses (see for instance p 776 of the second volume). Also, under 17.3 disconnect statement, general rule 6: 6) If any SQL-connection in L is active, then an exception condition is raised: invalid transaction state — active SQL-transaction. (L is a list of SQL-connections - see general rule 5) Sorry for not bringing this up earlier, but I've been sick and the required karma to consult the SQL standard was not restored until today. JDBC does not have much to say on the issue, from Connection.close(): It is strongly recommended that an application explicitly commits or rolls back an active transaction prior to calling the close method. If the close method is called and there is an active transaction, the results are implementation-defined. The reason I react on the currently proposed solution, is the use of an XA related SQLState. Can anyone explain to me why we want use that when calling close on a normal SQL connection with an uncommitted transaction on it? And is the SQL standard (2003) the authoritative source on this issue? I do agree with David that the generic invalid transaction state is a bit vague, but since we have several subclasses (including one for this specific case), we can elaborate on it if that is the correct way to go. thanks, -- Kristian 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:27388308 +++ db/derby/code/trunk/java/client/org/apache/derby/client/am/Connection.java 2006/03/24 00:55:44388309 [snip] // The following precondition matches CLI semantics, see SQLDisconnect() if (!autoCommit_ inUnitOfWork_ !allowCloseInUOW_()) { throw new
Re: Should network client and engine be *required* to match SQL States? (was Re: [jira] Commented: (DERBY-1149) 'jdbc40/StatementTest.junit' fails under DerbyNetClient)
David W. Van Couvering wrote: 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. This s a requirement if one want be able to run a test both in embedded and client/server mode with the same canon. Maybe that approach, running tests in both frameworks and compare, could be used to detect differences between client and embedded. Maybe existing canon can give hints to where there is a difference. -- Øystein Grøvlen, Senior Staff Engineer Sun Microsystems, Database Technology Group Trondheim, Norway
Re: Should network client and engine be *required* to match SQL States? (was Re: [jira] Commented: (DERBY-1149) 'jdbc40/StatementTest.junit' fails under DerbyNetClient)
I think you have a good point, and I think that what we can shoot for is over time targetting having the same canons for embedded and network client. Of course, if we took the original intent of the 'am' (Abstract Machine) package and put it on top of both the embedded and network code, then a lot of this would be taken care of forthwith. But that is easier said than done :) David Oystein Grovlen - Sun Norway wrote: David W. Van Couvering wrote: 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. This s a requirement if one want be able to run a test both in embedded and client/server mode with the same canon. Maybe that approach, running tests in both frameworks and compare, could be used to detect differences between client and embedded. Maybe existing canon can give hints to where there is a difference.
Re: [jira] Commented: (DERBY-1149) 'jdbc40/StatementTest.junit' fails under DerbyNetClient
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
Re: [jira] Commented: (DERBY-1149) 'jdbc40/StatementTest.junit' fails under DerbyNetClient
Hi, Kristian, thanks for your research on this! I didn't know there was more to be said on what SQL States should be used when. It's a little daunting -- every time I change a SQL State in the client I have to peruse this massive tome. Anyway, I would probably use 25001, which is currently not in use. And IMHO we should fix the embedded client to use this more descriptive message. I suppose I should fix this since it was my changes that introduced the regression. David Kristian Waagan wrote: 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'm a bit confused. The SQL spec (2003) seem to think that closing a connection with an active transaction is to be considered an invalid transaction state. INVALID_TRANSACTION_STATE_NO_SUBCLASS = 25000. INVALID_TRANSACTION_STATE_ACTIVE_SQL_TRANSACTION = 25001. There are more subclasses (see for instance p 776 of the second volume). Also, under 17.3 disconnect statement, general rule 6: 6) If any SQL-connection in L is active, then an exception condition is raised: invalid transaction state — active SQL-transaction. (L is a list of SQL-connections - see general rule 5) Sorry for not bringing this up earlier, but I've been sick and the required karma to consult the SQL standard was not restored until today. JDBC does not have much to say on the issue, from Connection.close(): It is strongly recommended that an application explicitly commits or rolls back an active transaction prior to calling the close method. If the close method is called and there is an active transaction, the results are implementation-defined. The reason I react on the currently proposed solution, is the use of an XA related SQLState. Can anyone explain to me why we want use that when calling close on a normal SQL connection with an uncommitted transaction on it? And is the SQL standard (2003) the authoritative source on this issue? I do agree with David that the generic invalid transaction state is a bit vague, but since we have several subclasses (including one for this specific case), we can elaborate on it if that is the correct way to go. thanks, -- Kristian 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:27388308 +++ db/derby/code/trunk/java/client/org/apache/derby/client/am/Connection.java 2006/03/24 00:55:44388309 [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
Re: Should network client and engine be *required* to match SQL States? (was Re: [jira] Commented: (DERBY-1149) 'jdbc40/StatementTest.junit' fails under DerbyNetClient)
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:27388308 +++ db/derby/code/trunk/java/client/org/apache/derby/client/am/Connection.java 2006/03/24 00:55:44388309 [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)
Re: Should network client and engine be *required* to match SQL States? (was Re: [jira] Commented: (DERBY-1149) 'jdbc40/StatementTest.junit' fails under DerbyNetClient)
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:27388308 +++ db/derby/code/trunk/java/client/org/apache/derby/client/am/Connection.java 2006/03/24 00:55:44388309 [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