Java和XA交易挑戰

Question

我在問這個問題，因爲我沒有在Google上發現一篇關於我的問題的至少一半的好文章。我對交易很陌生，希望得到答案，它簡要地介紹了Java EE環境中與XA交易相關的主要困難。

我的問題

1. 什麼是在Java XA事務的共同困難。
2. 在與不同框架（最受歡迎的Java EE）集成期間，XA事務有哪些困難？例如，如果第一個數據庫通過Hibernate工作，第二個數據庫通過MyBatis工作，配置XA事務是否是一項挑戰？
3. 對於多個數據庫供應商的XA交易情況如何？例如，第一個db - PostgreSQL，第二個 - H2。
4. 也許還有其他挑戰？
5. Spring和Hibernate怎麼樣？

P.S.

我不指望某人同時回答上述所有問題。如果您可以提供一個問題的答案，甚至可以提供一些有趣的參考資料，歡迎您！

Answer 1

我一直在使用XA生產，這是我的經驗。

• 具有分佈式事務增加顯著複雜事務管理：它很難監測是怎麼回事時，TX有多個參與者，這是很難對付的錯誤和恢復（2階段提交可能會失敗，並留下交易「 ），很難正確配置（關於分佈式tx的優化不是標準化的，例如最後的參與者優化），並且最終難以測試。在你走這條路之前考慮一切。

• 容器將「數據源」後面的連接池抽象化。如果您將持久性框架配置爲使用正確的XA數據源，它將參與分佈式tx。但是，持久性框架依賴於會話的概念來緩存對數據的更改。您通常無法控制事務發生時的真實情況。另外，對於緩存，持久性框架需要註冊一個鉤子以在事務提交時清除對緩存的更改。對於分佈式事務，事件排序和緩存一致性問題變得更難處理。

如果可以，請不要使用XA。