db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-5166) Database internal lock timeouts do not return exceptions on the executeUpdate of a jdbc Statement object
Date Mon, 20 Feb 2012 23:29:34 GMT

     [ https://issues.apache.org/jira/browse/DERBY-5166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Mike Matrigali updated DERBY-5166:
----------------------------------

    Urgency: Normal
     Labels: derby_triage10_9  (was: )

A .java repro will make it more likely that someone will look at this one.  Does this still
reproduce for you after other changes
you submitted related to lock timeouts and error handling in XA?
                
> 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
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message