JTA 事务中的 Hibernate 会话范围与 Open-Session-In-View
在会话范围方面，使用 JTA 事务与 Hibernate 对比使用 Open-Session-In-View 的说法是否正确？
据我所知，JTA 事务中的会话范围是一个事务（主要基于此链接），而在 Open-Session-In-View 模式中，会话的范围是请求，您可以在其中包含多个事务。
我问的是，首先要了解，其次要验证“谁”负责使用 JTA 时的会话处理。
目前，当使用Open-Session-In-View时，我有一个HibernateUtil类来处理会话的打开、检索和关闭（通过ThreadLocal)。
当我切换到使用 JTA 时，Hibernate 会处理上述会话操作吗？ （可能是我调用 userTransaction.begin，userTransaction.rollback 的衍生）
顺便说一句，我正在询问 JTA 因为我需要跨 Hibernate 协调事务 JMS 和 EHCache 因此这不是一般的最佳实践“让使用 JTA”问题。
一泰
Is it correct to say that using JTA Transactions with Hibernate contrasts using the Open-Session-In-View with regards to the session scope?
From what I've been able to gather the Session scope in the JTA Transactions is a transaction (mainly based on this link) while in the Open-Session-In-View pattern the session's scope is the requrest and you can have multiple transactions in it.
I'm asking, first to understand, and secondly to verify "Who" is responsible for the session handling when using JTA.
Currently, when using the Open-Session-In-View, I have a HibernateUtil class which handles opening, retrieving and closing of sessions (via ThreadLocal<Session>).
When I'll switch over to using JTA will Hibernate handle the above session actions? (as a derivative maybe of my calling userTransaction.begin,userTransaction.rollback)
BTW, I'm asking about JTA as I need to coordinate a transaction across Hibernate JMS and EHCache so this isn't a general best-practices "lets-use-JTA" question.
Ittai
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
好吧，如果您使用 JTA，那么 JTA 管理器（通常是 EJB3 容器）负责事务。
通常，使用相同的旧式 open-transaction-in-view 模型，但是使用
UserTransaction以及 SWING 客户端，可以拥有跨越多个请求的持久事务（尽管这是一个糟糕的做法）一般练习）。祝你好运。我发现外部事务管理器（我使用过 Atomikos）+ Spring 比 JBoss 更能满足我的需求。
Well, if you're using JTA then the JTA manager (usually EJB3 container) is responsible for transactions.
Typically, the same good old open-transaction-in-view model is used, however with
UserTransactionand, say, a SWING client it's possible to have long-lasting transactions spanning multiple requests (though it's a bad practice in general).Good luck. I found that external transaction manager (I've used Atomikos) + Spring worked better for my needs than JBoss.