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

        

Mime
View raw message