[
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.java
I'm attempting to write a test for this bug. What symptom should I be looking
for? The bug description mentions that the cancellation timer will fail as the
transaction no longer exists after preparing a read-only transaction.
I tried to reproduce this by running the attached program, which prepares a
read-only transaction with a 20 second timeout. After 20 seconds, I see the
following printed to derby.log:
The XA transaction timed out and is going to be rolled back. The transaction
Xid is (1,0102,0304).
However, I don't see any failures. What's missing in order to reproduce the
failures?
(I guess an alternative way to reproduce the bug would be to start a new
transaction using the same xid after preparing the first one, and checking if
the second transaction gets cancelled by the timer from the first transaction.)
> 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
