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 呢？

附言

我不希望有人一次性回答上述所有问题。如果您可以提供一个问题的答案，甚至提供一些有趣的参考资料，欢迎您！

Answer 1

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

• 分布式事务显着增加了事务管理的复杂性：当 tx 有多个参与者时，更难监控正在发生的事情，更难处理错误和恢复（2 阶段提交可能会失败并将事务留在-doubt")，更难正确配置（关于分布式交易的优化不是标准化的，例如最后一个参与者优化），最后更难测试。在你走这条路之前考虑到所有这些。

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

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