XA/JTA 事务还在使用吗?
我有一个与多个数据库和一些自定义服务交互的应用程序。对于某些操作,我需要类似事务的行为,其中一组更改要么跨所有数据库/服务提交,要么在发生错误时全部回滚。
X/Open 组的 XA 标准和 Java JTA 似乎使用两阶段提交过程正好解决了这个问题。一些数据库(mySQL、Postgres、Oracle)支持这些接口,但我感觉它们不经常使用或受欢迎程度正在下降。这是真的吗?如果是这样,为什么?
我知道 mySQL 上的 XA 存在一些与复制相关的问题。此外,XA 事务可能会明显变慢。 XA 不受欢迎/不常见还有其他原因吗?
I have an application that interacts multiple databases and some custom services. For some operations, I need transaction-like behavior where a set of changes either commit across all databases/services or all roll back if an error occurs.
The XA standard from the X/Open group and the Java JTA seem to solve exactly this problem using a two-phase commit process. Some databases (mySQL, Postgres, Oracle) support these interfaces, but I get the feeling that they are not often used or declining in popularity. Is that true? And If so, why?
I know there were some replication-related issues with XA on mySQL. Also, XA transactions can be significantly slower. Are there any other reasons why XA is unpopular / uncommon?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
XA 有以下几点:
There are several point with XA:
它们仍然用于您提到的用途。如果对其中一个数据库的操作失败,那么所有操作都会回滚。
它们速度较慢,因此如果不需要 XA(即它是自主操作或非事务性操作),则不应使用它。
Java EE 容器甚至可能会强制您在处理多个 DB 时使用 XA 数据源。
They are still used for exactly what you have mentioned. If an operation on one of the databases fails then it all gets rolled back.
They are slower, and so if XA is not needed (i.e. it's an autonomous operation or non-transactional), then it should not be used.
The Java EE container may even force you to use an XA datasource when dealing with multiple DBs.