Java 和 XA 事务挑战

Question

关闭。这个问题需要多问 focused 。目前不接受答案。

---

想要改进此问题吗？更新问题，使其仅关注一个问题 editing this post .

已关闭 9 年前。

Improve this question

我问这个问题是因为我在谷歌上没有找到一篇好文章可以涵盖我的问题的至少一半。我是事务新手，希望得到答案，该答案简要揭示了 Java EE 世界中与 XA 事务相关的主要困难。

我的问题

1. Java 中的 XA 事务有哪些常见困难。
2. XA 事务在与不同框架(最流行的 Java EE)集成时遇到哪些困难？例如，如果第一个数据库通过 Hibernate 工作，第二个数据库通过 MyBatis 工作，那么配置 XA 事务是否是一个挑战？
3. 多个数据库供应商的 XA 事务怎么样？例如，第一个数据库 - PostgreSQL，第二个数据库 - H2。
4. 也许还有其他挑战？
5. Spring 和 Hibernate 怎么样？

附注

我不希望有人立即回答上述所有问题。如果您可以提供一个问题的答案，甚至提供一些有趣的引用资料，我们非常欢迎!

Answer 1

我一直在生产中使用 XA，这是我的经验。

• 分布式事务显着增加了事务管理的复杂性:当交易有多个参与者时，更难监控正在发生的情况，更难处理错误和恢复(两阶段提交可能会失败并使交易“不确定”)，更难正确配置(有关分布式交易的优化未标准化，例如最后一个参与者优化)，最后更难测试。在你走这条路之前，请考虑所有这些。

• 容器抽象了“数据源”背后的连接池。如果您将持久性框架配置为使用正确的 XA 数据源，它将参与分布式交易。然而，持久性框架依赖于 session 的概念来缓存对数据的更改。您通常无法控制交易中事情何时真正发生。此外，对于缓存，持久性框架需要注册一个钩子(Hook)，以便在事务提交时将更改刷新到缓存。对于分布式事务，事件排序和缓存一致性问题变得更难处理。

如果可以的话，不要使用 XA。