是否使用JTA事务?

发布于 2024-10-12 11:27:15 字数 266 浏览 11 评论 0原文

我正在开发一个部署在 JBoss 应用程序服务器上的 J2EE 应用程序。 该应用程序由 EJB 2.x 组件和 Web 组件组成,运行在本地计算机或远程服务器上。数据库是 Oracle 或 SQL Server,并且不处于分布式环境中。

我使用 Hibernate 3.6(JPA 2.0 实现)进行事务。我应该使用容器管理事务 JTA 还是使用它太过分了?

目前我正在使用JTA,事实证明它运行良好,但有一些小问题,我不知道它是否与事务管理有关。使用本地事务管理会更容易或更可靠吗?

I am developing a J2EE application which is deployed on JBoss application server.
The application is composed of an EJB 2.x component and a web component and is running on local computer or remote server. The database is either Oracle or SQL Server and is not in a distributed envrionment.

I am using Hibernate 3.6 (JPA 2.0 implementation) for the transactions. Should I use JTA which is container managed transaction or is it overkilled to use it?

Currently I am using JTA and it turns out it is running fine but with some small issues which I do not know whether it is related to the transaction management or not. Will it be easier or more reliable to use local transaction management?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

沙沙粒小 2024-10-19 11:27:16

我建议使用 XA 事务,即使应用程序当前仅访问一种资源(数据库)。原因:

1)将来,如果应用程序决定包含当前数据库之外的其他事务资源,它会发现更容易,因为 XA 事务管理已经就位,并且可以将多个事务资源组合成单个事务。

2)由于您当前只有一个事务资源,因此与本地事务相比,我认为使用 XA 不会影响性能。原因是 XA/JTA 事务管理器已经针对单一事务资源的情况进行了某种优化(他们称之为单阶段优化)。

希望有帮助。

镍丁

I would recommend to use XA transaction, even if the application currently accesses only one resource (the database). Resons:

1) In future, if the application decides to include some other transactional resource apart from the current database, it will find it easier as the XA transaction management is already in place and the multiple transactional resources can then be combined into a single transaction.

2) As you have a single transactional resource currently, I don't think performance would suffer with use of XA compared to local transaction. The reason is that XA/JTA transaction managers already do some kind of optimization for cases of single transactional resource (they call it one-phase optimization).

Hope that helps.

Nitin

离去的眼神 2024-10-19 11:27:15

始终建议将 JTA 事务置于其他类型的事务 API 之上,特别是当您引用仍属于 JPA API 一部分的本机事务时。请注意,您不能说“JTA 与资源本地事务”,因为 JTA 实际上管理资源本地事务等。

Gavin King(Hibernate 的创建者)曾在一次采访中表示,这个特定于 JPA 的 API 是一个错误,应该首选更灵活的 JTA API。特别是在使用声明式事务时,JTA 非常轻量级。 “overkill”这个词实际上更多地适用于使用 JPA 本机事务 API,然后适用于使用 JTA。

关于使用 XA 或资源本地事务与 JTA 之间的选择,有一些话要说。有关更多详细信息,请参阅我的答案: JPA2+Hibernate 3.6.0 中的 JTA 或 LOCAL 事务?

我确实想知道为什么您将 EJB 2 与 JPA 2.0 结合使用。 EJB 3.1 在这里将是一个更合理的选择。 EJB 2 已完全弃用(将在 Java EE 7 中删除)。

JTA transactions are always recommended above other kinds of transaction APIs, especially if you are referring to the native transactions that are still part of the JPA API. Note that you can't say 'JTA vs resource local transactions', as JTA actually manages resource local transactions among others.

Gavin King (creator of Hibernate) once indicated in an interview that this JPA specific API was a mistake and that the much more flexible JTA API should be preferred. Especially when using declarative transactions, JTA is very lightweight. The word overkill would actually apply more to using the JPA native transaction API, then to using JTA.

There is something to say about the choice between using XA or resource local transactions with JTA. See my answer here for some more details about that: JTA or LOCAL transactions in JPA2+Hibernate 3.6.0?

I do wonder why you are using EJB 2 in combination with JPA 2.0. EJB 3.1 would be a much more logical choice here. EJB 2 is completely deprecated (will be pruned in Java EE 7).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文