JMS事務-開銷-如有可能，如何避免呢？

Question

在我們的應用程序中，我們從JMS Topic接收消息。

• 首先，我想知道JMS是否遵循FIFO策略。 如果不是，應用程序如何確定最新消息？

我們消耗消息（持久的訂戶和JMS會話被處理，開銷很大），因為消息保留在JMS服務器上，直到事務提交/結束。 我們指定交易的原因是

• 我們正在使用緩存（休眠）技術和使用它的事務。 因此，我們正在使用兩個事務，一個是JMS tx，一個是緩存技術tx。 當我們使用該消息時，我們希望在消息提交並將確認發送到JMS之前不發生任何事情。 緩存tx將首先提交，然后立即JMS tx將再次提交並確認消息，否則，兩個tx都將回滾並重播該消息。 當前，我們將消息重播3次，然后，如果仍然發生異常，則將消息發送到不可處理的隊列。

• 在許多消息同時發送到JMS並需要由我們的系統同時處理之前，這種方法可以正常工作。

• 我想知道您遇到這種情況時做了什么。 因為，維護持久預訂和事務處理會話是JMS服務器上的一大筆開銷，並且會耗盡服務器的性能。

Answer 1

JMS規范中未指定主題的消息排序，因此對此的官方答案是特定於JMS實現。 話雖這么說，除非特別重寫以執行其他操作，否則我認為消息將以FIFO順序傳遞。

對於事務，建議您考慮實施兩個階段的提交XA事務，因此您不需要兩個單獨的事務。 如果您的緩存實現支持XA，則JMS和Cache（和DB）事務將是相同的。

通常，我發現對於這些類型的事務處理消息，如果必須使用事務處理消息，則降低性能的最佳方法是在一個事務中處理盡可能多的消息：

1. 開始交易
2. 檢索n條消息（或所有消息，直到出現超時）
3. 處理消息
4. 提交交易。
5. 轉到1。

用一顆石頭殺死兩只鳥的另一種方法是在檢索過程中跳過對消息的處理，而只是將檢索到的消息寫入事務處理的數據存儲中。 然后，有一個單獨的線程（按時間戳順序）從存儲中檢索消息並進行處理（單獨的線程-=單獨的事務）。