db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2220) Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
Date Wed, 07 Mar 2007 15:18:24 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478794

Knut Anders Hatlen commented on DERBY-2220:

Is point 2 (Forbid the call to XAConnection.close when there is a global transaction associated
with the corresponding resource) a necessary part of this bug fix, or would it be better to
discuss/fix it under a separate issue?

It seems to me the patch correctly implements what you have described. I'm a little confused
after reading the discussion. Was there ever consensus that the described approach was correct?
It does sound correct to me, but I haven't studied all the different standards mentioned.

Some small questions and comments to the try4 patch:
  - could NetXAResource.currentXid have been private?
  - abortCurrentTransaction() checks (e.errorCode != XAException.XA_RBOTHER && e.errorCode
!= XAException.XA_RBROLLBACK). Would it make sense to test (errorCode < XA_RBBASE || errorCode
> XA_RBEND) instead?
  - ClientPooledConnection (super class of ClientXAConnection) calls close() in its finalize
method (existing code). With the new exception thrown by ClientXAConnection.close(), could
that cause a problem when an active XAConnection is garbage collected?
  - should XATransactionTest have been added to jdbcapi._Suite so that it runs under suites.All?
  - I think the suite() method could be simplified to "return TestConfiguration.defaultSuite(...)"
  - the Statement objects in testXAConnection() are not closed
  - in previous discussions about JUnit tests it has been mentioned that referencing constants
in org.apache.derby.shared.common.reference.SQLState in tests is not recommended. Instead
one should hard code the SQL state (in this case "25000") in the test. Also, I would recommend
using BaseJDBCTestCase.assertSQLState() instead of assertTrue(ex.getSQLState().equals...).
  - there is a test for XAConnection.close() that is supposed to fail. What about adding a
test case where it doesn't fail?
  - I'm not a big fan of finally clauses in the tests, since exceptions in them might hide
the original error. Putting the cleanup code outside the finally clause would only be a problem
if the test fails, and I agree with Dan's previous comment about not optimizing tests for
the time when they fail.

> Uncommitted transactions executed throught XAResource will held locks after the application
terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>                 Key: DERBY-2220
>                 URL: https://issues.apache.org/jira/browse/DERBY-2220
>             Project: Derby
>          Issue Type: Bug
>    Affects Versions:
>         Environment: Solaris Nevada build 49, Sun's JDK1.6
>            Reporter: Julius Stroffek
>         Assigned To: Julius Stroffek
>         Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat,
d2220_try2.diff, d2220_try2.stat, d2220_try4.diff, d2220_try4.stat, XATranTest.java, xxx.sql
> Using this piece of code derby will not release a table lock of 'dummy' table.
>             String query = "insert into dummy (field1) values ('" + Integer.toString(value)
+ "')";
>             XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB",
"", "");
>             XAResource xaResource = xaConnection.getXAResource();
>             conn = xaConnection.getConnection();
>             Xid xid = createXid(value);        
>             xaResource.setTransactionTimeout(10);
>             xaResource.start(xid, XAResource.TMNOFLAGS);
>             Statement statement = conn.createStatement();
>             statement.execute(query);        
>             // terminate the client application
>             // this will not release any locks
>             System.exit(0);

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message