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自带的 服务器）
现在的问题是我想坚持使用本地事务，但其他团队成员想使用 JTA。过去 9 年里我一直在使用 J2EE，我一次又一次地听到人们建议如果我不需要两阶段提交就坚持使用本地事务。这不仅是出于性能原因，而且本地事务的调试/故障排除比 JTA 容易得多（即使 JTA 仅在需要时进行单阶段提交）。
我的建议是使用 spring 声明式事务管理 + 本地事务（HibernateTransactionManager） 而不是容器 JTA
我想确定我是否偏执或者我有一个有效的观点。我想听听 Java EE 世界其他人的想法。或者请给我指出一篇合适的文章。
We are in the process of re-thinking our tech stack and below are our choices (We can't live without Spring and Hibernate due to the complexity etc of the app). We are also moving from J2EE 1.4 to Java EE 5.
Technology stack
- Java EE 5
- JPA 2.0 (I know Java EE 5 only supports
JPA 1.0 but we want to use Hibernate
as the JPA provider) - Hibernate 3.6.0 (We already have
lots of hbm files with custom types
etc. so we doesn't want to migrate
them at this time to JPA. This means
we want both jpa/hbm mappings work
together and hence the Hibernate as
the JPA provider instead of using
the default that comes with App
Server)
Now the problems is that I want to stick with local transactions but other team members want to use JTA. I have been working with J2EE for last 9 years and I've heard time and again people suggesting to stick with local transactions if I doesn't need two phase commits. This is not only for performance reasons but debugging/troubleshooting a local transaction is lot easier than a JTA (even if JTA only does single phase commit when required).
My suggestion is to use spring declarative transaction management + local transactions (HibernateTransactionManager) instead of container JTA
I want to make sure if I am being paranoid or I have a valid point. I'd like to hear what the rest of the Java EE world thinks. Or please point me an appropriate article.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
正如 Duffy 已经提到的，JTA 并不是两阶段提交的同义词，两阶段提交是通过 XA 协议完成的。
例如，在 JBoss AS 中，您可以明确选择给定数据源是 xa-datasource 还是 tx-datasource。在这两种情况下，事务都是通过 JTA 进行管理的。
在某些情况下，您可能已经在不知不觉中使用了 JTA。如果您以事务方式发送 JMS 消息，或者在修改数据库中的某些内容的同一事务中更新事务缓存，则事务管理器会自动切换到 XA 模式。代表数据库的数据源可能不是 XA，但在 XA 事务中，允许 1 资源是非 XA。然后通过
最后一次资源提交优化对该资源进行更新。尽管您应该始终计算风险并进行自我测试，但我确实想警告不要产生毫无根据的恐惧。 XA 似乎是我们作为开发人员从小就害怕的事情之一。最近 JBoss 论坛上对此有一个有趣的讨论：何时使用 xa -数据源。
问题是，XA 在过去可能是一项复杂的技术，其实现低于标准，但自从这次 FUD 以来近十五年了，情况可能不再是这样了。 1995 年复杂的大型企业的东西是 2011 年常见的普通技术。
将其与我们曾经对 EJB 的恐惧进行比较，现在这已经完全无关紧要了，或者对虚拟机的恐惧（显然不是Java 程序员的问题），或者当你真正参与这个行业很长一段时间时，担心做一些像函数调用这样基本的事情；）
As Duffy already mentioned, JTA is not synonymous with 2 phase commit, which is something done via the XA protocol.
In JBoss AS for example, you can explicitly choose whether you want a given data source to be an xa-datasource or a tx-datasource. In both cases, transactions are managed via JTA.
In some cases you might already have been using JTA without knowing it. If you send a JMS message transactionally, or update a transactional cache in the same transaction where you modify something in a database, the transaction manager automatically switches to XA mode. The datasource representing your DB may not be XA, but in an XA transaction 1 resource is allowed to be non-XA. Updates to this resource then happens via the
last resource commit optimization.Although you should always calculate the risks and test for your self, I do want to warn against unfounded fear. XA seems to be one of those things we as developers have been brought up to fear. There was an interesting discussion on the JBoss forum about this recently: when to use xa-datasource.
The thing is that XA might have been a complex technology with sub-par implementations in the past, but almost a decade and a half since this FUD this might not be the case anymore. What was complex big enterprise stuff in 1995 is your common run of the mill technology in 2011.
Compare this with the fear we were once brought up with for EJB, which is now completely irrelevant anymore, or the fear for virtual machines (obviously not a problem for Java programmers), or when you're really participating in this industry for a long time, the fear for doing something as basic as function calls ;)
JTA 并不意味着两阶段提交。我认为 JTA 和 XA 驱动程序的组合使两阶段提交成为可能。
我仍然建议使用 JTA 和声明性事务，而不是在代码中嵌入事务逻辑。事务最好以面向方面的方式完成，就像 Spring 那样。
更新：
根据您发布的附加信息，我同意您的论点。我建议使用 Spring 声明式事务和 HibernateTransactionManager 类。
JTA doesn't mean two phase commits. I think it's the combination of JTA and XA drivers that makes two phase commits possible.
I'd still recommend using JTA and declarative transactions over embedding transaction logic in code. Transactions are best done in aspect oriented fashion, a la Spring.
UPDATE:
With the additional information you've posted, I agree with your argument. I'd recommend using Spring declarative transactions and the HibernateTransactionManager class.