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 "Kathey Marsden (JIRA)" <ji...@apache.org> on 2011/04/07 00:36:05 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=13016588#comment-13016588 ] 

Kathey Marsden commented on DERBY-5166:
---------------------------------------

Thank you Guy for reporting this issue. Could you post a  java program  to reproduce the problem?


> 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