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 "Guy Pardon (JIRA)" <ji...@apache.org> on 2011/03/31 15:34:05 UTC
[jira] [Created] (DERBY-5166) Database internal lock timeouts do
not return exceptions on the executeUpdate of a jdbc Statement object
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
[jira] [Updated] (DERBY-5166) Database internal lock timeouts do
not return exceptions on the executeUpdate of a jdbc Statement object
Posted by "Mike Matrigali (Updated) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (DERBY-5166) Database internal lock timeouts do
not return exceptions on the executeUpdate of a jdbc Statement object
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ 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