You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Myrna van Lunteren (JIRA)" <ji...@apache.org> on 2014/02/26 23:41:21 UTC
[jira] [Commented] (DERBY-5166) Database internal lock timeouts do
not return exceptions on the executeUpdate of a jdbc Statement object
[ https://issues.apache.org/jira/browse/DERBY-5166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13913639#comment-13913639 ]
Myrna van Lunteren commented on DERBY-5166:
-------------------------------------------
output with 10.6.2.1 - (999685):
$ java XAReproD5166
2014-02-26 22:35:47.784 GMT : Apache Derby Network Server - 10.6.2.1 - (999685) started and ready to accept connections on port 1597
creating or connecting to the database
creating tab (i int, j int) and inserting a row (1,0)
1. create two xids (xid1, xid2) with same gtrid and different branchqualifiers.
2. conn1 = get XA connection
3. xaResource1 = conn1.getXAResource()
4. xaResource1.start(xid1,XAResource.TMNOFLAGS)
5. update row X (set j=1 where i=1) via conn1 (using a Statement.executeUpdate call)
6. xaResource2 = conn2.getXAResource()
7. xaResource2.start(xid2,XAResource.TMNOFLAGS)
8. update row X (set j=2 where i=1) via conn2
Expected Exception 2 java.sql.SQLTransactionRollbackException: DERBY SQL error: SQLCODE: -1, SQLSTATE: 40XL1, SQLERRMC: 40XL1
9. check the value of X via conn1
found the row: 1, 1
Connection ok. got right value
Exception in thread "main" java.sql.SQLNonTransientConnectionException: A network protocol error was encountered and the connection has been terminated: the requested command encountered an unarchitected and implementation-specific condition for which there was no architected message (additional information may be available in the derby.log file on the server)
at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown Source)
at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source)
at org.apache.derby.client.am.Connection.createStatement(Unknown Source)
at org.apache.derby.client.am.LogicalConnection.createStatement(Unknown Source)
at XAReproD5166.checkConn(XAReproD5166.java:126)
at XAReproD5166.main(XAReproD5166.java:106)
Caused by: org.apache.derby.client.am.SqlException: A network protocol error was encountered and the connection has been terminated: the requested command encountered an unarchitected and implementation-specific condition for which there was no architected message (additional information may be available in the derby.log file on the server)
at org.apache.derby.client.am.SqlException.copyAsUnchainedSQLException(Unknown Source)
at org.apache.derby.client.am.Sqlca.chainDeferredExceptionsToAgentOrAsConnectionWarnings(Unknown Source)
at org.apache.derby.client.am.Sqlca.getJDBCMessage(Unknown Source)
at org.apache.derby.client.am.SqlException.getMessage(Unknown Source)
at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source)
at org.apache.derby.client.am.Statement.executeUpdate(Unknown Source)
at XAReproD5166.main(XAReproD5166.java:84)
> Database internal lock timeouts do not return exceptions on the executeUpdate of a jdbc Statement object
> --------------------------------------------------------------------------------------------------------
>
> Key: DERBY-5166
> URL: https://issues.apache.org/jira/browse/DERBY-5166
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.6.2.1
> Environment: Mac OSX with Java
> Reporter: Guy Pardon
> Labels: derby_triage10_9
> Attachments: XAReproD5166.java
>
>
> Steps to reproduce:
> 1. create two Xids (xid1, xid2) with the _same_ gtrid value and _different_ branchqualifiers
> 2. conn1 = get XA connection
> 3. xaResource1 = conn1.getXAResource()
> 4. xaResource1.start(xid1,XAResource.TMNOFLAGS)
> 5. update row X via conn1 (using a Statement.executeUpdate call)
> 6. xaResource2 = conn2.getXAResource()
> 7. xaResource2.start(xid2,XAResource.TMNOFLAGS)
> 8. update row X via conn2
> 9. check the value of X via conn1
> Observed behavior: step 8 hangs for a while (I assume it blocks on a lock and times out) and step 9 returns the value from _before_ step 5 - i.e., the unchanged, original value.
> The only hypothesis I find consistent with this is the following:
> -step 8 blocks and returns after the transactions are rolled back (and the locks released)
> -step 9 then returns the value after rollback, i.e. the original value
> If this is the case, then step 8 should not return OK but rather throw an SQLException
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)