[
https://issues.apache.org/jira/browse/QPID-4541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13561290#comment-13561290
]
Rajith Attapattu commented on QPID-4541:
----------------------------------------
Kieth, I would let Weston to explain the exact use case from an XA pov, as he
has more details and knowledge about the use case.
Instead I will try to explain the root cause and the fix I made.
By default the JMS client will replay unacked message transfers (after
failover) in it's replay buffer unless the session is marked transacted.
(If we allow replay in a transacted session, then we will have messages
produced or consumed outside of the transaction boundaries, which violates
atomocity).
For XA transactions the same applies. If we replay messages after failover it
will result in messages consumed or produced outside of the transaction
boundaries.
However the XA implementation does not use a transacted JMS session underneath
as the transaction is governed by the XA manager.
So it uses an AUTO_ACKED session underneath, which replays message transfers
after failover.
The patch I submitted allows this to be turned off based on a boolean argument.
Does that make sense? If it's still not clear please feel free to ask further
questions.
Rajith.
> Messages are replayed after XA commit in a failover scenario
> ------------------------------------------------------------
>
> Key: QPID-4541
> URL: https://issues.apache.org/jira/browse/QPID-4541
> Project: Qpid
> Issue Type: Bug
> Components: Java Client, JCA
> Affects Versions: Future
> Environment: All supported OS platforms, all supported JEE platforms
> Reporter: Weston M. Price
> Assignee: Rajith Attapattu
>
> Currently we are seeing an issue in failover scenarios where messages that
> are received and the XA transaction completes are replayed on the nth node of
> a cluster when failover is invoked. This appears to be similar to QPID-2294
> in the violation of transaction atomicity.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
