[
https://issues.apache.org/jira/browse/AMQ-7485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17108260#comment-17108260
]
Gary Tully commented on AMQ-7485:
---------------------------------
There is an existing rollbackOnly flag that we can check in a producer and flip
in the RAR managed connection context. This flag is reset on the next
transaction boundary which is what we want.
In this way, any use of a producer on a session with an aborted transaction
will fail early and report an illegal state, preventing any spurious non
transacted message production in error.
> 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)
