db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brett Bergquist (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (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 13:22:39 GMT

    [ 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 


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