[ 
https://issues.apache.org/jira/browse/DERBY-5562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13184563#comment-13184563
 ] 

Brett Bergquist commented on DERBY-5562:
----------------------------------------

It appears the timer was implemented in 
https://issues.apache.org/jira/browse/DERBY-2508 which has a fix at 10.3.1.4

                
> 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
>            Assignee: Knut Anders Hatlen
>         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

        

Reply via email to