[
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: 10.3.0.0
> 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.
