6

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

技术栈

  1. Java EE 5
  2. JPA 2.0（我知道 Java EE 5 只支持 JPA 1.0 但我们想使用 Hibernate 作为 JPA 提供者）
  3. Hibernate 3.6.0（我们已经有很多具有自定义类型等的 hbm 文件，所以我们现在不想将它们迁移到 JPA。这意味着我们希望两个 jpa/hbm 映射一起工作，因此 Hibernate 作为 JPA provider 而不是使用 App Server 附带的默认值）

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

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

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

4

2 回答 2

7

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

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

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

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

问题是 XA 在过去可能是一项复杂的技术，其实现低于标准，但自从这个 FUD 以来已经有将近 15 年了，这可能不再是这种情况了。1995 年复杂的大企业东西是 2011 年常见的磨机技术。

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

于 2011-01-02T12:20:37.703 回答
5

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

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

更新：

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

于 2010-12-30T03:29:54.147 回答