Mysql XA/JTA事务是否仍在使用？

我有一个可以与多个数据库和一些定制服务交互的应用程序。对于某些操作，我需要类似事务的行为，其中一组更改要么跨所有数据库/服务提交，要么在发生错误时全部回滚

X/Open组的XA标准和javajta似乎正是通过两阶段提交过程解决了这个问题。一些数据库（mySQL、Postgres、Oracle）支持这些接口，但我感觉它们不常被使用，或者受欢迎程度正在下降。这是真的吗？如果是，为什么

---

我知道mySQL上的XA存在一些与复制相关的问题。此外，XA事务的速度可能会显著降低。XA不受欢迎/不常见还有其他原因吗？

它们仍然用于您所提到的用途。如果其中一个数据库上的操作失败，则会回滚所有数据库

它们速度较慢，因此如果不需要XA（即，它是一个自治操作或非事务性操作），则不应使用它

---

Java EE容器甚至可能迫使您在处理多个数据库时使用XA数据源。

XA有几个要点：

• 它完成了自己的任务，没有被接受的替代方案。如果必须使用分布式事务，那么XA是没有办法的
• 它是“标准技术”，没有炒作，也没有营销。因此，它在大多数人的雷达下飞行
• 即使在使用它时，Jack Application Developer也很有可能不知道它，因为大多数部分通常隐藏在某些框架中
• XA的需求确实有所下降，因为面向服务的体系结构（SOA）和消息队列是一种被炒作的体系结构范式，它们试图避免子系统之间的如此紧密耦合。尽管至少SOA似乎也在很好地衰退
• XA中经常被遗忘的部分是事务实际中断时使用的必需代码和工具。XA中有一些郊区，事务管理器在相当长的一段时间内既不能提交也不能回滚所有资源。这一点只会增加“只有当你真的必须使用它”这一点

---

XA仅在所有（或除一个以外的所有）数据源都支持两阶段提交的情况下工作良好。2PC有一些开销，需要更多的监控，以确保放弃的准备提交不会留下来阻塞数据库。当您需要跨多个系统的事务行为时，它非常有用，但如果您不需要，最好避免使用它以降低复杂性。>那么就不应该使用它。-实现可以自动优化并检测是否根本没有完成任何事务性工作，或者事务性工作最多涉及1个本地事务。请参阅，例如，实际上第二点是不正确的。如果您使用两个Oracle数据库并对两个Oracle数据库进行更改，则不需要XA。@Steve:我很困惑：第二点是关于宣传和营销。但你评论的后半部分与第一点“没有可接受的替代方案”更为吻合。我没有说，地球上没有其他选择，只有大多数其他星展银行也支持的选择。此外：XA的一个关键点是，没有“大师级”DB，但场上只有平等的球员加上一名裁判（TX经理）。对于DB-Link，所有参与者必须就一个“主”DB达成一致，该DB设置了链路，因此是单点故障。因此，在我看来，这并不是真正的“分布式”。你的假设是错误的，分布式事务不等于XA的使用。@Steve：你是对的，对于同构系统，也有特定于供应商的解决方案。但对于异构系统，我不知道还有任何其他技术在实践中符合要求。你…吗？