db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guy Pardon (JIRA)" <j...@apache.org>
Subject [jira] [Created] (DERBY-5166) Database internal lock timeouts do not return exceptions on the executeUpdate of a jdbc Statement object
Date Thu, 31 Mar 2011 13:34:05 GMT
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


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 is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message