[
https://issues.apache.org/jira/browse/DERBY-5523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mamta A. Satoor updated DERBY-5523:
-----------------------------------
Issue & fix info: Release Note Needed
Urgency: Normal
Labels: derby_triage10_9 (was: )
> XA Transactions can becomes stuck if a connection from a XAResource without a
> timeout terminates after performing work but before ending
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-5523
> URL: https://issues.apache.org/jira/browse/DERBY-5523
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.8.1.2
> Environment: Solaris 10
> Reporter: Brett Bergquist
> Labels: derby_triage10_9
>
> If using a connection with no timeout starts an XA transaction with
> xaRes.start(xid, XAResource.TMNOFLAGS);
> and some work is done but the application fails without calling
> xaRes.end(xid, XAResource.TMSUCCESS)
> then another application cannot join that transaction using
> xaRes.start(xid, XAResource.TMJOIN)
> and then commit or rollback the transaction. Basically the transaction is
> ACTIVE but cannot be rolled back or committed and will exist until the
> database server is restarted.
> This is similar to DERBY-2220. With DERBY-2220, it too will not work if the
> XAResource does not have a timeout specified either. This is simple to test
> by using the test code attached to DERBY-2220 and comment out the setting of
> the timeout. Once doing so, the transaction will be maintained and the locks
> will not be released.
> This might be a deviation from the XA standard but I cannot tell. It seems
> as if a XA connection does not have a timeout set is active (that is
> XAResource.start has been called but XAResource.end has not) and the
> connection gets closed, the XA transaction should be rolled back implicitly.
> This is being done if the XAResource has a timeout set so it seems that it
> would not be too hard to do in this case either.
--
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
