[
https://issues.apache.org/jira/browse/DERBY-5562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-5562:
--------------------------------------
Attachment: d5562-1a-with-test.diff
Thanks. The attached patch adds a test case that exposes the bug. It prepares a
read-only transaction that has a timeout, and then starts a new transaction
with the same Xid and no timeout. The second transaction sleeps for while to
make sure it exceeds the timeout of the first transaction. The second
transaction is aborted because of the bug, and the test case fails. With the
fix, the transaction is not aborted, and the test case passes.
The patch also moves the fix from EmbedXAResource to XATransactionState, so
that all handling of the timer is private to that class. I also made
XATransactionState.xa_finalize() private to emphasize this (and removed the
synchronized modifier since all callers already synchronize before calling the
method).
All the regression tests ran cleanly with this patch.
> 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, d5562-1a-with-test.diff
>
>
> 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
