XA/JTA 事务还在使用吗?

发布于 2024-12-20 05:37:38 字数 288 浏览 1 评论 0原文

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

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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

2024-12-27 05:37:38

XA 有以下几点:

  • 它完成它的工作并且没有公认的替代方案。如果必须使用分布式事务,那么就没有办法绕过 XA。
  • 它是“标准技术”,没有炒作,没有营销。因此,它在大多数人的雷达之下飞行。
  • 即使使用它,Jack 应用程序开发人员也很可能不知道它,因为大多数部分通常隐藏在某些框架中。
  • 对 XA 的需求确实有所下降,因为面向服务的架构 (SOA) 和消息队列是大肆宣传的架构范例,它们试图避免子系统的紧密耦合。尽管至少SOA看起来也正在衰落得相当不错。 ;-)
  • XA 中经常被遗忘的部分是事务实际中断时所需的代码和工具。在 XA 的某些郊区,事务管理器在相当长的一段时间内既不能提交也不能回滚所有资源。这一点只会增加“只有在确实必须时才使用它”这一点。

There are several point with XA:

  • It does its job and there is no accepted alternative. If you must use distributed transactions, then there is no way around XA.
  • It is "standard technology", no hype and no marketing. Therefore it flies below the radars of most people.
  • Even when it is used, there is a good chance that Jack Application Developer does not know it as most parts are usually hidden in some frameworks.
  • The need for XA is indeed somewhat on decline, because Service Oriented Architecture (SOA) and message queuing are hyped architecture paradigms which try to avoid such tight coupling of subsystems. Although at least SOA also seems to be declining quite well. ;-)
  • Often forgotten parts of XA are the required code and tools which are used when a transaction actually breaks. There are some outskirts in XA where the Transaction Manager can neither commit nor rollback all resources for quite some time. This point only increases the "use it only if you really must" point.
桃气十足 2024-12-27 05:37:38

它们仍然用于您提到的用途。如果对其中一个数据库的操作失败,那么所有操作都会回滚。

它们速度较慢,因此如果不需要 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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文