为什么使用DefaultMessageListenerContainer强烈建议使用sessionTransacted

的Javadoc DefaultMessageListenerContainer说为什么使用DefaultMessageListenerContainer强烈建议使用sessionTransacted

强烈建议要么将“sessionTransacted”为“true” 或指定一个外部“transactionManager的”。

为什么强烈推荐？这个神秘建议背后是什么？

2014-10-09 mabn

因为重新交货比交易更容易。 – 2014-10-09 14:23:34

我不希望重新交付，应用程序代码负责处理此事（消息消费者与非事务性资源进行一些交互，因此决定是否/何时应该重发/重新传递消息不是微不足道的）。我相信我有意识地选择了AUTO_ACKNOWLEDGE，但是在javadoc中的评论暗示还有更多。 – mabn 2014-10-09 14:47:12

如果您的会话未处理，那么在JVM意外关闭的情况下，您可能会丢失信息。

这里是各个ACK模式中的从用AbstractMessageListenerContainer的解释：

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

"sessionAcknowledgeMode" set to "AUTO_ACKNOWLEDGE" (default): Automatic message acknowledgment before listener execution; no redelivery in case of exception thrown. 
"sessionAcknowledgeMode" set to "CLIENT_ACKNOWLEDGE": Automatic message acknowledgment after successful listener execution; no redelivery in case of exception thrown. 
"sessionAcknowledgeMode" set to "DUPS_OK_ACKNOWLEDGE": Lazy message acknowledgment during or after listener execution; potential redelivery in case of exception thrown. 
"sessionTransacted" set to "true": Transactional acknowledgment after successful listener execution; guaranteed redelivery in case of exception thrown.

确切行为可能根据变化给具体的听众容器和JMS提供者使用。

由于消息传递通常基于有保证的传递，因此建议使用可提供最佳安全功能的方法来防止消息丢失。如果它值得的话，你必须决定一个特定的用例。

来源

2014-10-09 14:28:24

我知道交付模式，并且他们被充分描述 - 这就是为什么我想知道为什么Spring作者暗示应该使用DefaultMessageListenerContainer sessionTransacted。它不像它比例如AUTO_ACKNOWLEDGE（相同但更好）。它具有不同的语义，这些模式不可互换。所以基本问题是 - 如果除了粘贴文档中的内容外，还没有使用sessionTransaced，会发生什么情况。 – mabn 2014-10-09 14:37:14

AUTO_ACKNOWLEDGE不考虑异常或JVM /线程关闭。使用AUTO_ACKNOWLEDGE会告诉ActiveMQ开头并删除任何持久消息。所以它不是真的一样，更好取决于你的要求。同样，这个建议是基于大多数人希望保证交付的事实。如果您的JVM或线程发生故障，您将失去AUTO_ACKNOWLEDGE消息，而如果将sessionTransacted设置为true，则ActiveMQ仍然可以将其重新传递给另一个使用者，或者当它返回时发生故障。 – 2014-10-09 15:07:08

谢谢，有道理。 – mabn 2014-10-09 15:14:45

为什么使用DefaultMessageListenerContainer强烈建议使用sessionTransacted

回答

相关问题