[
https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julius Stroffek updated DERBY-2220:
-----------------------------------
Attachment: d2220_beta2.diff
What about the second patch?
I changed the code to maintain the list of all uncommitted transactions and
rollback all of them. This should cover the whole problem not only the previous
simple case.
The patch will forbid using the code like this one
XAConnection xaConnection =
createXAConnection("jdbc:derby://localhost:1526/TestDB", "", "");
XAResource xaResource = xaConnection.getXAResource();
conn = xaConnection.getConnection();
XAConnection xaConnection2 =
createXAConnection("jdbc:derby://localhost:1526/TestDB", "", "");
XAResource xaResource2 = xaConnection2.getXAResource();
Xid xid = createXid(value);
xaResource.start(xid, XAResource.TMNOFLAGS);
Statement statement = conn.createStatement();
statement.execute(query);
xaResource.end(xid, XAResource.TMSUCCESS);
// commiting a transaction on different resource
xaResource2.prepare(xid);
xaResource2.commit(xid, false);
It will force the user to commit or rollback the transaction on a same
connection as it was executed. I went through JTA API and have not found
anything that will state that the JTA implementation have to allow
commit/rollback of a transaction on different connection than the unit of work
was executed on. At least the specification forbids resuming a suspended
transaction on different connection than it was started on. Then I think made
also no sense to require to commit or rollback the transaction on the different
connection than the unit of work was executed on.
There exists 1:1 mapping between XAConnection instance and XAResource instance.
The XAResource methods use the corresponding logical connection to pass
commands to a database.
Please provide any further comments on this.
> 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, 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.
