XA事務中的數據一致性

Question

假設我們有一個參與XA事務的數據庫（例如Oracle）和JMS提供者（例如HornetQ）。 消息被發送到JMS隊列，並且一些數據在同一分布式事務中保留在數據庫中。 提交事務后，消息使用者將讀取持久數據並在單獨的事務中處理它們。

關於第一個XA事務，事務管理器可以執行以下事件序列（例如JBoss）

1. 准備（HornetQ）
2. 准備（甲骨文）
3. 提交（HornetQ）
4. 提交（Oracle）

如果消息使用者在HornetQ中完成提交后開始讀取數據，但仍在Oracle中執行，會發生什么？ 消息使用者是否會讀取陳舊數據？

這個問題可以推廣到參與XA事務的任何類型的多個資源，即是否有可能存在一個小的時間窗口（當執行提交階段時），其中來自另一個並發事務的讀者可以獲得不一致的狀態（通過讀取已提交一個資源的數據和另一個資源的陳舊數據）？

我想說，事務資源阻止這種情況的唯一方法是在准備階段完成后阻止受影響數據的所有讀者，直到發布提交。 這樣，上面提到的示例消息使用者將阻塞，直到數據在數據庫中提交。

Answer 1

不幸的是，XA事務不支持一致性。 當映射到CAP定理時， XA解決了跨多個數據存儲的可用性和分區容錯。 這樣做必須犧牲一致性。 使用XA時，您必須擁抱最終的一致性。

無論如何，創建CP或AP的系統都很難 ，無論您的數據存儲或事務模型如何，您都將面臨此問題。

Answer 2

我對基於Weblogic JMS和Oracle 11g的一些不同環境有一些經驗。 在這個答案中，我認為它的工作方式完全相同 。 我希望我的回答能幫到你。

在我們的案例中，有一個“遠程”系統，必須根據本地系統內發生的不同事件進行通知。 另一個系統也紅色進入我們的數據庫，因此用例似乎與您的問題幾乎相同。 事件的順序與您的事件非常相似。 在測試系統上沒有一個單一的faulire。 每個人都認為它會起作用但我們中的一些人懷疑它是否是正確的解決方案。 隨着軟件的出現，一些BPM流程無法預測。 所以對你的問題的答案很簡單： 是的，這是可能的 ，每個人都應該意識到這一點。

我們的解決方案 （在我看來）並不是一個計划周密的解決方案 ，但我們認識到兩次提交之間的時間窗口正在制動系統，因此我們在隊列中添加了一些“延遲”（如果我記得它就像1- 2分鍾）。 它足以完成其他提交並讀取一致的數據。 在我看來，這不是最好的解決方案。 它沒有解決同步問題（如果oracle事務超過1-2分鍾怎么辦？）。

這是一篇值得一讀的精彩博客文章，最后的解決方案對我來說似乎是最好的。 我們在其他系統中實現了它，並且它的工作方式更好。 重要的是要注意您應該限制重試（重新讀取）以防止“卡住”線程。 （有一些錯誤報告。）有了這個限制，我到目前為止找不到更好的解決方案，所以如果有人有更好的選擇，我期待聽到它。 :)

編輯：錯別字。

Answer 3

是。 外部系統可以在數據庫實際提交之前接收和使用您發送的消息，即使事務失敗並在之后回滾。

在過去兩年中，我一直在使用XA事務來維護和開發分布式系統，其中WebSphere MQ作為JMS提供者，Oracle 11g作為后備DB。
其中一個批處理作業將從DB讀取脫機消息，將它們發送到JMS並將它們標記為在DB中發送 - 所有這些都是同一XA事務的一部分。 如果任何消息或數據庫失敗，則將回滾該事務。

有時，消息對於JMS來說太大並導致send（）失敗並且整個事務回滾（），使DB保持不變。
但是 ，外部使用者仍在接收和處理回滾之前發送的每條消息。 我知道，因為他們會給每個處理過的郵件發送一封電子郵件，我收到很多關於未標記為在DB中發送的郵件的電子郵件（因為該事務已被回滾）。

如果這個外部系統以某種方式SELECT COUNT（*）我的系統發送的消息數量，它將讀取0條消息，盡管已經消耗了數百條消息。

所以，是的，即使使用XA事務，外部系統也可以讀取陳舊數據。

Answer 4

我將插入一個狀態字段，因此在每個步驟之后，如果成功，狀態將更新，並且讀者應在執行操作之前檢查狀態。