JPA2+Hibernate 3.6.0 中的 JTA 或 LOCAL 事务？答案

【问题标题】：JTA or LOCAL transactions in JPA2+Hibernate 3.6.0?JPA2+Hibernate 3.6.0 中的 JTA 或 LOCAL 事务？
【发布时间】：2011-06-01 09:06:44
【问题描述】：

我们正在重新考虑我们的技术堆栈，以下是我们的选择（由于应用程序的复杂性等，我们不能没有 Spring 和 Hibernate）。我们也在从 J2EE 1.4 迁移到 Java EE 5。

技术栈

Java EE 5
JPA 2.0（我知道 Java EE 5 只支持 JPA 1.0 但我们想使用 Hibernate 作为 JPA 提供者）
休眠 3.6.0（我们已经有大量具有自定义类型的 hbm 文件等等，所以我们不想迁移他们此时到了JPA。这意味着我们希望 jpa/hbm 映射都能正常工作在一起，因此休眠状态为 JPA 提供程序而不是使用 App自带的默认服务器）

现在的问题是我想坚持使用本地事务，但其他团队成员想使用 JTA。在过去的 9 年里，我一直在使用 J2EE，并且我一次又一次地听到有人建议如果我不需要两阶段提交就坚持使用本地事务。这不仅是出于性能原因，而且本地事务的调试/故障排除比 JTA 容易得多（即使 JTA 只在需要时进行单阶段提交）。

我的建议是使用spring声明式事务管理+本地事务（HibernateTransactionManager）而不是容器JTA

我想确定我是偏执狂还是我的观点是正确的。我想听听 Java EE 世界的其他人是怎么想的。或者请给我一篇合适的文章。

【问题讨论】：

标签： java jpa jpa-2.0 jta

【解决方案1】：

正如 Duffy 已经提到的，JTA 不是 2 阶段提交的同义词，它是通过 XA 协议完成的。

例如，在 JBoss AS 中，您可以明确地选择您希望给定的数据源是 xa-datasource 还是 tx-datasource。在这两种情况下，事务都是通过 JTA 管理的。

在某些情况下，您可能已经在不知不觉中使用了 JTA。如果您以事务方式发送 JMS 消息，或者在修改数据库中的某些内容的同一事务中更新事务缓存，事务管理器会自动切换到 XA 模式。代表您的数据库的数据源可能不是 XA，但在 XA 事务中，允许 1 资源是非 XA。然后通过last resource commit optimization 更新此资源。

尽管您应该始终为自己计算风险并进行测试，但我确实想警告不要毫无根据的恐惧。 XA 似乎是我们作为开发人员一直害怕的事情之一。最近在 JBoss 论坛上有一个有趣的讨论：when to use xa-datasource。

问题是 XA 在过去可能是一项复杂的技术，但在过去近 15 年的时间里，这种情况可能不再是这样了。 1995 年复杂的大企业的东西是 2011 年常见的磨机技术。

比较一下我们曾经对 EJB 的恐惧，现在完全无关紧要了，或者对虚拟机的恐惧（对于 Java 程序员来说显然不是问题），或者当你真正参与这个行业时很长一段时间，害怕做一些像函数调用这样基本的事情；）

【讨论】：

您写道：“代表您的数据库的数据源可能不是 XA，但在 XA 事务中，允许 1 资源是非 XA。”为什么在这种情况下允许非 XA ？事实上，在事务提交后，它不能倾向于关于结果的全局性的不连贯的行为吗？例如，如果这个非 XA 资源不支持 2-phases-commit，我们如何确保全局事务（针对多个数据源）顺利进行？
@Mik378 看看我对last resource commit optimization 的概念。如果轮到最后一个资源提交，您会知道之前不知道的一件事：所有其他资源都可以提交。因此，完整的 TX 是否可以提交仅取决于最后一个资源，这很简单。如果它确实提交，则整个 TX 都被提交（意思是其他的，已经说过他们可以提交），如果它没有提交（例如 throws），那么其他的都被回滚。
我不知道“最后一次资源提交”的概念。现在我明白了规则“最多允许一个非 XA 数据源，不再允许”谢谢 :)

【解决方案2】：

JTA 并不意味着两阶段提交。我认为 JTA 和 XA 驱动程序的组合使两阶段提交成为可能。

我仍然建议使用 JTA 和声明性事务，而不是在代码中嵌入事务逻辑。事务最好以面向方面的方式完成，就像春天一样。

更新：

根据您发布的其他信息，我同意您的论点。我建议使用 Spring 声明性事务和 HibernateTransactionManager 类。

【讨论】：

对。想法使用弹簧进行交易。我理解 JTA 并不真正意味着 2 阶段，但我的观点是，如果我们已经知道我们不想要 2 阶段，那么为什么要选择 JTA？
我的建议是使用spring声明式事务管理+本地事务
如果我使用本地事务，那么我不需要在 spring 中定义“org.springframework.transaction.jta.JtaTransactionManager”bean。我只是定义“HibernateTransactionManager”或“JpaTransactionManager”
谢谢。我越来越难以说服他们接受我的方法。他们说我提出的两点（性能和难以调试）太抽象了，我没有足够的数据来证明这一点。您能想到使用 JTA 的任何其他缺点或将本地 trans 与 spring 声明式 trans 一起使用的优点吗？他们还建议使用 EJB 3 和 CMT。
我想看看他们的数据来证明他们的观点。我敢打赌，你们俩都没有任何数据。他们在为EJB3和CMT争论不休，板着脸批评Spring？请。它归结为 Spring 或 EJB 3.1 偏好。对您来说，好消息是任何一个都可以。当然，我更喜欢春天。您可以通过根据接口编写所有内容来推迟您的选择。您可以在不影响客户端的情况下切换实现。