MDB和複製消息

讓我們假裝MDB已收到消息並已開始在CMT/Required事務中處理它，並假設該事務可能需要一些時間才能完成。MDB和複製消息

在這種情況下，當第一個事務仍在進行中時，是否有可能在另一個事務中接收和處理另一個MDB實例的重複消息？

或者容器是否會確保在MDB忙於處理CMT/Required事務中的消息時，其他MDB實例將不會收到相同消息的複製？

2011-08-01 CoffeeDriven

我期望的任何消息被鎖定，而交易的一部分，重複不應該被髮送，因爲JMS規範要求：

4.4.15重複郵件的製作： JMS提供者必須從不產生重複的消息。這意味着生成消息的客戶端可以依靠其JMS提供程序來確保消息的使用者僅接收一次消息。

所以我覺得你可以依靠消息提供者，以確保除非首先是明確地回滾或交易超時，隱式回滾MDB沒有收到該郵件的第二個副本。這兩個操作都應該「解鎖」消息並使其可用於重新傳遞到MDB，同時JMSRedelivered設置爲true並且JMSXDeliveryCount遞增。

我懷疑在一個（或多個）EJB，JCA或JTA規範（或J2EE）中有更多的需求來補充JMS規範，我沒有檢查過。

來源

2011-08-01 13:17:04 strmqm

'4.4.15重複生成消息：JMS提供程序絕不能產生重複消息。這意味着生成消息的客戶端可以依賴其JMS提供程序來確保消息的使用者只會收到一次。「是關於AUTO_ACKNOWLEDGE還是一般情況？因爲在'DUPS_OK_ACKNOWLEDGE'中，我認爲JMS提供者可以發送愚蠢的消息。而在MDB中，所有確認模式都被忽略。這就是爲什麼我有點困惑。 – CoffeeDriven

一般。 4.4.15只適用於工作單位的範圍內;在發生事務性回滾的情況下，消息肯定有可能被多次傳遞給MDB。但在交易退出之前，您只能獲得一份副本。至於DUPS_OK，這表明它可以做出延遲確認，並且存在發生崩潰的風險，可能不會記錄確認，並且可以在重新啓動後重新發送消息。通過設置DUPS_OK，客戶說它不介意以這種方式重複。但這不適用於XA/MDB的情況。 – strmqm

* 4.4.15 *指消息的**生產**，而不是**生產**。在* 4.4.14 *中提到，在自動確認模式中，最後消費的消息可能會被重新發送。 – CoffeeDriven

MDB和複製消息

回答

相關問題