带和不带Spring JMS的自动确认模式之间的差异

我试图理解JMS中的确认模式是如何工作的。我当时正在阅读这篇文章，它让我非常困惑，因为它与Spring的文档所说的内容相矛盾

有消息说, 从

当消息从receive（）方法成功返回时，会自动确认消息。如果接收方使用MessageListener接口，则当消息从onMessage（）方法成功返回时，消息将自动得到确认。如果在执行receive（）方法或onMessage（）方法时发生故障，消息将自动重新传递

从

在AUTO_ACKNOWLEDGE模式下，确认总是onMessage（）处理程序返回后隐式发生的最后一件事。接收消息的客户机可以通过在使用会话上指定客户机确认模式，对保证消息的传递进行更细粒度的控制

Spring博士还说了其他事情： 从

侦听器容器提供以下消息确认选项：

“sessionAcknowledgeMode”设置为“AUTO_ACKNOWLEDGE”（默认值）：在侦听器执行之前自动确认消息；在引发异常的情况下不重新交付。 “sessionAcknowledgeMode”设置为“CLIENT_ACKNOWLEDGE”：侦听器成功执行后自动确认消息；在引发异常的情况下不重新交付。 “sessionAcknowledgeMode”设置为“DUPS_OK_ACKNOWLEDGE”：侦听器执行期间或之后的延迟消息确认；在引发异常的情况下可能重新交付。 “sessionTransacted”设置为“true”：侦听器成功执行后的事务确认；在引发异常的情况下保证重新交付

---

我想知道的是为什么这些消息来源说了不同的话？如果所有这些都是真的，那么我如何知道我的消息将如何/何时被确认？

您错过了抽象容器javadocs中的关键短语

具体的行为可能会因具体的侦听器容器和使用的JMS提供程序而异。

Spring

中最常用的侦听器容器是

DefaultMessageListenerContainer

，它确实显示了这种行为-它用于事务（本地或外部事务管理器），以便能够回滚已确认的消息。它的侦听器在receive方法之后被调用，因此已经应用了标准的JMS自动确认。线程上的任何

JmsTemplate

操作也可以使用相同的会话，因此可以是事务的一部分

另一方面，

SimpleMessageListenerContainer

使用传统的

MessageListener

并显示标准JMS行为（在

receive（）

返回之前，从

使用者调用侦听器；因此异常将停止ack）

我建议您阅读这些具体实现的javadocs。从
SMLC

This is the simplest form of a message listener container. It creates a fixed 
number of JMS Sessions to invoke the listener, not allowing for dynamic 
adaptation to runtime demands. Its main advantage is its low level of 
complexity and the minimum requirements on the JMS provider: Not even the 
ServerSessionPool facility is required.

See the AbstractMessageListenerContainer javadoc for details on acknowledge 
modes and transaction options.

For a different style of MessageListener handling, through looped 
MessageConsumer.receive() calls that also allow for transactional reception of 
messages (registering them with XA transactions), see 
DefaultMessageListenerContainer.

我将为抽象容器上的文档打开一个JIRA问题，因为我可以看出它可能会误导。
感谢您的澄清，Gary。