AUTO_ACKNOWLEDGEMENT模式與使用和不使用Spring JMS之間的區別

Question

我想了解JMS中的確認模式是如何工作的。我正在閱讀這個源文件，它讓我非常困惑，因爲它與Spring的文檔所說的相矛盾。

來源說一兩件事： 從http://www.javaworld.com/article/2074123/java-web-development/transaction-and-redelivery-in-jms.html

當它成功地從接收（）方法返回的消息被自動確認。如果接收方使用MessageListener接口，則消息在從onMessage（）方法成功返回時會自動確認。如果在執行receive（）方法或onMessage（）方法時發生故障，則會自動重新發送消息。

從http://www2.sys-con.com/itsg/virtualcd/Java/archives/0604/chappell/index.html

隨着AUTO_ACKNOWLEDGE模式的確認總是在onMessage（）處理程序返回後隱含發生的事。通過在消費會話中指定CLIENT_ACKNOWLEDGE模式，接收消息的客戶端可以更好地控制保證消息的傳遞。

春文件說其他的東西： 從http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/jms/listener/AbstractMessageListenerContainer.html

監聽器容器提供了以下消息確認選項：

「SessionAcknowledgeMode來」 設置爲 「AUTO_ACKNOWLEDGE」（默認）：自動聽衆執行前的消息確認;在拋出異常情況下無法重新投遞。 「sessionAcknowledgeMode」設置爲「CLIENT_ACKNOWLEDGE」：成功偵聽器執行後自動確認消息;在拋出異常情況下無法重新投遞。 「sessionAcknowledgeMode」設置爲「DUPS_OK_ACKNOWLEDGE」：偵聽器執行期間或之後的惰性消息確認;在拋出異常的情況下可能的重新傳遞。 「sessionTransacted」設置爲「true」：成功偵聽器執行後的事務性確認;保證在發生異常情況下的重新投遞。

我想知道的是，爲什麼這些消息來源說不同的東西？如果一切都是真的，那麼我怎麼知道我的消息將如何/何時被確認？

Answer 1

你錯過了從抽象容器的javadoc關鍵短語...

The exact behavior might vary according to the concrete listener container and JMS provider used.

在Spring中最常用的偵聽容器是DefaultMessageListenerContainer這確實表現出的行爲 - 其意圖用於交易（本地或外部交易管理器），以便能夠回滾已經確認的消息。它的監聽器在接收方法之後調用，所以標準的JMS auto-ack已經被應用。線程上的任何JmsTemplate操作也可以使用相同的會話 - 因此可以是事務的一部分。

在另一方面，SimpleMessageListenerContainer使用傳統的MessageListener並呈現的標準JMS行爲（聽者從Consumer之前返回調用;因此例外將停止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問題，因爲我可以看到，它可能會產生誤導。