与jms确认模式相关的混淆

Question

我有一个多个使用者正在监听一个队列，并且当一个消息到达它的onMessage（）函数时被调用。由于有多个消费者，每个消费者都有自己的会话。要求是只有在没有问题且没有例外的情况下才应该确认消息......）

AUTO_ACK模式：我的理解是：消息在onMessage成功完成后得到确认。如果onMessage（）中有异常，则会重新传递消息。客户端确认：在onMessage（）的结尾，我明确地调用了确认（）。如果发生错误，则不会调用acknowledge（）方法，因此消息将被重新发送。 事务处理会话：我在onMessage（）函数末尾调用session.commit（），以防发生某种异常，并调用session.rollback，因此消息将被重新传递。

消费者可以检测到重复的消息并进行适当的处​​理。我的问题是，所有3种模式都在做同样的事情并解决我的目的，所以哪种方法比其他方法好，为什么？总之，为什么我应该通过客户端确认或自动模式使用事务处理会话。 我不想使用JTA/XA，因为它不受所有jms提供程序示例activeMQ支持，它会使我的应用程序变慢。

如果我的消费者无法处理重复消息，那么我明白我唯一的选择是使用JTA/XA，因为所有其他选项都会再次向我发送消息，这会导致重复处理。在JTA/XA中，我也可以再次得到消息，但它不会被认为是重复的处理，因为之前的事务会被回滚。

Answer 1

请注意这里的应答模式之间的差异，因为它们可能比您想象的更微妙。

当在onMessage中使用自动确认并引发异常时，您的消息可能会重新传递给另一个客户端，同一个客户端或进入DLQ，具体取决于您的代理以及它的配置方式。

许多人忽视了客户端承认的事情是，客户端确认实际上是为先前的会话交付所有以前的消息，因此如果您在同一个会话中有多个消费者，它的消息也可能会被您的确认呼叫。因为在你的情况下，你每个会话都有一个消费者，那么你可以回到自动确认的情况，在这种情况下消息将被重新传递或者可能转到DLQ。

在本地事务案例中，消息通常会在重新分派给某个其他使用者或路由到DLQ之前，基于客户端或代理配置重新向同一客户端重新发送数次。

在某种程度上，您选择的模式取决于您对多次失败结果的期望，以及如何配置您选择的Broker实施来处理这种情况。