[
https://issues.apache.org/jira/browse/DERBY-5562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183253#comment-13183253
]
Brett Bergquist commented on DERBY-5562:
----------------------------------------
The failure is that the transaction timeout is not canceled when it should be
and will produce a message in the log when this is the case.
The test needs to create a XA transaction with timeout (I used the
derby.jdbc.xaTransactionTimeout to set the timeout), start the XA transaction,
use read-only SQL to the database and then prepare the XA transaction. The
prepare code detects that only read-only work was done and implicitly commits
the transaction. The prepare returns XA_RDONLY and you do not commit the
transaction in the test code. The timer started by the "start" method will not
be canceled and the timer will continue and when fired will try to rollback the
transaction that has already be implicitly committed and ended.
See issue
https://issues.apache.org/jira/browse/DERBY-960
which fixed the prepare to return XA_DDONLY.
> An read-only XA transaction that has a timeout never has the timer canceled
> when the transaction is complete
> ------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-5562
> URL: https://issues.apache.org/jira/browse/DERBY-5562
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.8.2.2
> Environment: Solaris 10
> Glassfish V2.1.1
> Reporter: Brett Bergquist
> Attachments: D5562.java, DERBY-5562.patch
>
>
> From the EmbedConnection.java comment for "xa_prepare".
> // On a prepare call, xa allows an
> optimization that if the
> // transaction is read only, the RM can
> just go ahead and
> // commit it. So if store returns this
> read only status -
> // meaning store has taken the liberty
> to commit already - we
> // needs to turn around and call
> internalCommit (without
> // committing the store again) to make
> sure the state is
> // consistent. Since the transaction
> is read only, there is
> // probably not much that needs to be
> done.
> When XATransactionController.XA_RDONLY is returned, no "commit" or "rollback"
> will be received. If a XA transaction timer was started (could be through
> the derby.jdbc.xaTransactionTimeout=xxx for example), then these transactions
> will not have their timer canceled and will later attempt to cancel the
> transaction and fail as the transaction no longer exists.
--
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
