JPA2 + Hibernate 3.6.0中的JTA或LOCAL事务？
我们正在重新思考我们的技术堆栈，下面是我们的选择（由于应用程序的复杂性等原因，我们不能没有Spring和Hibernate）。 我们也从J2EE 1.4迁移到Java EE 5。
技术堆栈
- Java EE 5
- JPA 2.0（我知道Java EE 5仅支持JPA 1.0，但我们希望将Hibernate用作JPA提供程序）
- Hibernate 3.6.0（我们已经有很多带有自定义类型的hbm文件等，所以我们不想将它们迁移到JPA。这意味着我们希望jpa / hbm映射一起工作，因此Hibernate就像JPA一样提供程序而不是使用App Server附带的默认值）
现在问题是我想坚持本地交易，但其他团队成员想要使用JTA。 我已经使用J2EE工作了9年，我一次又一次地听到人们建议如果我不需要两个阶段提交就坚持本地交易。 这不仅是出于性能原因，而且本地事务的调试/故障排除比JTA容易得多（即使JTA仅在需要时进行单阶段提交）。
我的建议是使用spring声明式事务管理+本地事务（HibernateTransactionManager）而不是容器JTA
我想确定我是偏执狂还是有一个有效的观点。 我想听听Java EE世界其他人的想法。 或者请给我一个合适的文章。
JTA并不意味着两阶段提交。 我认为这是JTA和XA驱动程序的组合，可以进行两阶段提交。
我仍然建议使用JTA和声明式事务而不是在代码中嵌入事务逻辑。 交易最好以面向方面的方式完成，即spring。
更新：
根据您发布的其他信息，我同意您的观点。 我建议使用Spring声明式事务和HibernateTransactionManager类。
正如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以来差不多十五年，这可能不再是这种情况了。 1995年复杂的大企业是什么，是2011年磨机技术的共同运行。
相比之下，我们曾经为EJB带来的恐惧，现在已经完全无关紧要了，或者对虚拟机的恐惧（显然对Java程序员来说不是问题），或者当你真正参与这个行业很长时间时间，害怕做一些像函数调用一样基本的东西;）