XA或非XA的JMS和DB操作

我是相當新的XA和非XA的世界。我的要求是從隊列中讀取消息，直到出現NO消息。對於隊列中的每條消息，轉到數據庫並執行一些事務，如選擇，插入，更新。XA或非XA的JMS和DB操作

這是可能實現這一目標使用非XA數據源？我目前正在使用XA數據源，但瞭解到它的成本很高，性能受到影響。

感謝任何幫助！由於

2014-01-17 user726579

你應該解釋一下如何管理隊列，使用什麼產品。一些數據庫供應商還提供排隊解決方案，這將使您的生活更輕鬆。 – steve

如果您需要在您的交易，包括與JMS連接雙方交互（即發送或接收信息），並與數據庫連接，通過使用數據庫連接那麼你一定需要一個XA-數據源因爲您的交易是two-phase commit (2PC) transaction。

在兩階段提交事務你要麼更改提交到所有的資源（在你的情況JMS和DB資源），或者，如果出現錯誤與其中一方回滾所有更改。

要做到這一點，您需要連接到已啓用XA的數據源。此外，在Java EE容器中，JMS連接應已啓用XA-。

來源

2014-01-17 13:30:26 trikelef

XA保證一個消息匹配1和僅1 DB事務。讓我們覺得發生沒有XA（只是衆多可能的情況之一）：

的MDB挑一條消息
的MDB執行DB工作（讓我們說，每一件事情去了，不例外）
應用服務器的JDK崩潰出於某種原因或出現網絡故障，而MDB線程仍在運行
爲了簡單起見，讓我們考慮的是，重新啓動服務器：由於MDB沒有提交事務，爲此消息仍在隊列中。
另一個MDB獲取消息並重複數據庫事務。

對於我們的幸運，XA存在！ :-) 從表演角度來看，付費是有成本的，但總是質量（服務）有成本！

來源

2014-01-17 14:12:35 dmarrazzo

您在這裏做了幾個假設，這些假設不一定是正確的：數據庫和排隊系統都必須支持XA協議。 – steve

這些假設是在問題中。他說他可以在XA數據源和非XA之間進行選擇，但他擔心表演。 WebSphere Messaging確實支持XA，這是J2EE規範的要求。我只展示了XA如何提供幫助的例子。 – dmarrazzo

考慮1.5 phase commit。基本上是：

第1步：您提交DB交易
第2步：您提交JMS事務。

可能的錯誤情況：

DB事務失敗。
數據庫事務成功的JMS事務失敗。
全部成功。

不是1或3會使您的系統處於不一致的狀態。如果是1，則只需重新發送消息。

要處理方案2，您需要向系統引入重複檢查。所以基本上您的交易管理看起來像類似於這樣：

//pseudo code 
if (isDublicate(message)) 
    commitJMSTransaction(); 
else 
    doYourBusinessLogic(); 
    doYourDBOperation(); 
    commitDBTransaction(); 
    commitJMSTransaction();

如果JMS交易失敗的消息代理將重新嘗試發送郵件（或者你需要重新發送手動取決於你的經紀人設置），但你複製檢查將檢測到它並將其從隊列中刪除。

來源

2015-09-28 17:35:11 forgacan

感謝您的鏈接！ – rbp

爲了給你一個XA和NON-XA轉換的想法，我簡要解釋一下， XA事務是一個「全局事務」。非XA交易是「本地交易」。

XA事務涉及協調事務管理器，一個或多個數據庫（或其他資源，如JMS）都參與單個全局事務。如果它連接到多個數據庫，那麼它是XA。

非XA事務沒有事務協調器，並且單個資源正在完成其所有事務工作本身。這將只有一個數據庫作爲資源。

來源

2016-06-01 13:50:57 Sunny

XA或非XA的JMS和DB操作

回答

相關問題