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

ASF subversion and git services commented on AMQ-7485:
------------------------------------------------------

Commit 0ebb0f88ef2afc590bf19ba1ec08ed995669a9dc in activemq's branch 
refs/heads/master from gtully
[ https://gitbox.apache.org/repos/asf?p=activemq.git;h=0ebb0f8 ]

[AMQ-7485] add check for rollbackonly flag in session send such that failed 
ended transactions prevent further work till next transaction boundary


> RAR managed producer is unaware of timed out transaction; sends non 
> transacted message in error
> -----------------------------------------------------------------------------------------------
>
>                 Key: AMQ-7485
>                 URL: https://issues.apache.org/jira/browse/AMQ-7485
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: RAR, XA
>    Affects Versions: 5.15.0
>         Environment: JEE RAR
>            Reporter: Gary Tully
>            Assignee: Gary Tully
>            Priority: Major
>              Labels: RAR, XA, xaresource
>             Fix For: 5.16.0
>
>
> There is a problem with a RAR managed connection enlisted in a xa transaction 
> that aborts, if that connection is used to produce messages.
> getConnection succeeds and enlists the resource, the session is in an xa 
> transaction, all is good. 
> If however, the transaction times out and aborts, *before* a producer gets to 
> send(), the send will *not* see a transaction context and will produce a 
> message with no transaction identity in error.
> The abort forces an end(fail) and rollback, however this results in the 
> transaction context being unset and the producer session not being aware of 
> the aborted transaction.
> The transaction management is external in the case of a managed connection 
> and the default is non transactional in the absence of an external or RAR 
> local transaction. 
> Getting a reference to the TransactionManager and doing a transaction status 
> check before send is a workaround, but that should not be necessary.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to