[
https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475103
]
Julius Stroffek commented on DERBY-2220:
----------------------------------------
>From the XA Transaction Specification from the OpenGroup:
---
It is an error, [XAER_PROTO], for a transaction manager to call xa_close ()
within a
thread of control that is associated with a transaction branch (that is, the
transaction
manager must call xa_end() before calling xa_close ()).
---
So a change proposed in a patch is against this spec. It should be possible to
close a xa network connection on the trunk but not the ebedded one. To
implement this according a spec should be:
1.) undo any changes made to embedded connection
2.) check in the network client code (ClientXAConnection) when closing a
connection to a database whether it is already associated with the global
transaction. If so, do not allow a connection to be closed.
However, from my point of view it would be clearer to allow a connection to be
closed and rollback the associated transactions. I do not know whether it would
be possible to even make the behavior against the spec in some cases but I
would like to discuss the difference.
I would expect that a transaction manager or an application would call the
XAConnection.close when it is associated with a transaction only in a
exceptional case when it 'does not know what else to do'. This could happen
after throwing an unpredictable exceptions which do not have to be handled -
like NullPointerException. The handling of such an exception usually propagates
through couple of functions in the call stack. Usually, in this case the
application do not have to know the valid xid of the transaction or it do not
have to know even whether the xa connection is associated with the transaction
or not. What the application should do?
1.) If it uses a transaction manager, the xid is stored in a transaction
manager and if it has a reference to transaction manager it can do some work
with the transaction - probably roll back
2.) If it uses XAResource and XAConnection directly, it may happen that the
application will loose xid and not the XAResource or XAConnection references
(these might be shared across the application). What to do in this case?
I am trying to think of an application with not the optimal design. This leads
me what happens if all the objects would be garbage collected? ;-)
---
Now I think that the best approach is to implement XAConnection.close according
the specs and to provide the cleanup with rollback of transactions in
XAConnectionImpls.finalize methods (as it is implemented now in close methods
of the patch). I checked the code for this fastly and it looks like it is not
handled this way. I'll check this in more detail and I'll create a new jira
issue to address this separately.
> 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, 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.
