我正在閱讀Java EE教程的這一部分。 http://download.oracle.com/javaee/6/tutorial/doc/bncfu.html#bncfy指定JMS客戶端的消息持久性
而且有一個問題：如果我有一個JMS客戶端（而不是服務器）產生的信息，並將其發送給位於服務器上的目標隊列，這是否producer.setDeliveryMode（DeliveryMode.PERSISTENT）;仍然適用？
我的意思是不JMS客戶端支持任何機制來堅持的消息，或者是隻配備了供應商/服務器軟件？
感謝
因爲JMS只是一個規範，沒有什麼能夠阻止實現從客戶端提供的消息持久性的某一水平。但是，在實踐中，所有實現（我都知道）將其委託給經紀商。
請記住，消息的最初目的是在以同樣的方式，每一個節點也有一個TCP/IP，LU6.2或其他傳輸堆棧的每個節點有一個經紀人。從這個意義上來說，消息傳遞絕對應該是一種交通工具，而不是像數據庫這樣的中央服務。其目的是提供一種本地服務，將應用程序與網絡的不可用性以及無數可用的同步傳輸協議隔離開來。在這個模型中，經紀人總是本地和唯一的網絡通信是在兩個經紀人之間。
多年來，消息增加了客戶的能力，但這更多的是比建築許可費用。消息傳遞客戶端連接重新引入了對傳輸最初旨在屏蔽應用程序的同步網絡連接的依賴性。正如你的問題所說明的那樣，我們現在已經到了一個圈子 - 一個本地排隊的要求，以防止應用程序無法使用網絡。除了現在應用程序需要消息的本地持久性實際上是（據稱）異步消息傳遞應用程序。
我們當然可以建立一個當地的小券商，他們得到了中央的代理之前排隊的消息。但是在我們讓客戶端代碼變得更加複雜之前（並且邀請用更多異步消息傳遞支持異步消息傳遞的無限遞歸）之前，我建議再看看原始消息傳遞架構 - 將代理本地應用於需要的應用程序持續的水平。
對此的一種解決方法是將服務提供商應用程序與服務使用者應用程序區別開來。正是服務提供商需要深度持久的消息存儲，並且由於它們通常是事務性的，因此不能允許故障轉移到代理的其他實例（在這種情況下，XA資源管理器認可的「不同」）。
在另一方面，簡單的請求/響應應用程序可以繼續與他們沒有永久隊列在網絡上匿名連接到經紀商的輕量級層。這些應用在同步點之外發出請求消息並等待動態隊列上的回覆。如果它們故障轉移，它們可以重新發出請求，並且回覆將到達新節點。這些是網絡化，基於客戶端的消息傳遞的理想候選者，因爲他們對特定的代理沒有親和力。只要客戶端和服務器應用程序之間存在網絡跳轉，就不需要確保客戶端與服務器進行故障切換等。服務提供商有本地代理，服務消費者有兩個（或更多）輕量級中央代理連接到。
當然，這並不能滿足每一個異步通訊的要求，但它允許服務請求者共享集中的經紀人確實提供提供備案系統最高的可靠性的解決方案，並仍然保留許可成本。
哇，很多T.Rob的信息，雖然不知道他是否清楚地回答了這個問題。 :)
簡短的回答是肯定的，它確實適用。事實上，它是由消息生成客戶端指定告訴經紀人如何處理它。
保持本地持久性沒有太大意義，因爲如果代理（服務器）關閉，在嘗試producer.send（..）時會得到JMSException。
-Ed Y.
謝謝T.Rob，非常翔實！ – user567068 2011-02-27 23:45:16