JPA2+Hibernate 3.6.0中的JTA或本地事务？
我们正在重新思考我们的技术栈和下面是我们的选择(由于应用程序的复杂性等原因，我们无法生活在没有Spring和Hibernate的情况下)。我们还将从J2EE 1.4迁移到Java 5。
技术栈
- Java 5
- JPA2.0(我知道Java 5只支持JPA1.0，但我们希望使用Hibernate作为JPA提供程序)
- Hibernate 3.6.0 (我们已经有很多具有自定义类型的hbm文件，所以我们现在不想将它们迁移到JPA。这意味着我们希望jpa/hbm映射一起工作，因此Hibernate作为JPA提供程序，而不是使用App附带的默认值)
现在的问题是，我想继续处理本地事务，但其他团队成员希望使用JTA。在过去的9年里，我一直在使用J2EE，我多次听到人们建议，如果我不需要两个阶段提交，就应该坚持本地事务。这不仅是出于性能原因，而且本地事务的调试/故障排除要比JTA容易得多(即使JTA只在需要时进行单阶段提交)。
我的建议是使用spring声明性事务管理+本地事务(HibernateTransactionManager)而不是容器JTA
我想确定我是偏执狂还是我有一个正确的观点。我想听听其他Java世界的想法。或者请给我指一篇合适的文章。
回答 2
Stack Overflow用户
发布于 2010-12-30 03:29:54
JTA并不意味着两阶段提交。我认为JTA和XA驱动程序的结合使得两阶段提交成为可能。
我仍然建议使用JTA和声明性事务，而不是在代码中嵌入事务逻辑。事务最好是以面向方面的方式完成，即la Spring。
更新：
我同意你所发表的补充资料。我建议使用Spring声明性事务和HibernateTransactionManager类。
Stack Overflow用户
发布于 2011-01-02 12:20:37
正如达菲已经提到的，JTA不是2阶段提交的同义词，这是通过XA协议完成的。
例如，在JBoss中，您可以显式地选择给定的数据源是xa数据源还是tx数据源。在这两种情况下，事务都是通过JTA管理的。
在某些情况下，您可能已经在不知情的情况下使用JTA。如果您通过事务方式发送JMS消息，或者在修改数据库中某些内容的事务中更新事务缓存，事务管理器将自动切换到XA模式。表示您的DB的数据源可能不是XA，但是在XA事务中，1资源被允许为非XA。然后通过last resource commit optimization对此资源进行更新。
尽管你应该总是为自己计算风险和测试，但我确实想警告你不要有根据的恐惧。XA似乎是我们开发人员从小就害怕的事情之一。最近在JBoss论坛上有一个有趣的讨论：何时使用xa-数据源。
问题是XA可能是一项复杂的技术，在过去的实现中没有达到标准，但是自从这个FUD出现以来，已经有将近15年的时间了--这种情况可能不再是这样了。在1995年，复杂的大型企业产品是你在2011年共同使用的磨坊技术。
将这与我们曾经提出的对EJB (现在已经完全不相关了)的恐惧，或者对虚拟机的恐惧(显然不是Java程序员的问题)，或者当您真正参与这个行业很长一段时间，对做一些像函数调用这样基本的事情的恐惧进行比较;)
https://stackoverflow.com/questions/4559764
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号