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 "Mike Matrigali (Updated) (JIRA)" <ji...@apache.org> on 2012/02/21 00:29:34 UTC
[jira] [Updated] (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: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