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。