db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-5562) An read-only XA transaction that has a timeout never has the timer canceled when the transaction is complete
Date Tue, 10 Jan 2012 11:24:39 GMT

     [ 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:
>         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


View raw message