如何在 Tomcat 6 for Hibernate 中使用 JTA 支持？
他们建议在 Java EE 环境中使用 JTA 事务支持。
但是如何在Tomcat6中配置JTA以便Hibernate Session可以使用它呢？
从版本 3.0.1 开始，Hibernate 添加了
SessionFactory.getCurrentSession()方法。最初，假定使用 JTA 事务，其中 JTA 事务定义当前会话的范围和上下文。鉴于众多独立 JTA TransactionManager 实现的成熟度，大多数（如果不是全部）应用程序都应该使用 JTA 事务管理，无论它们是否部署到 J2EE 容器中。基于此，您只需要使用基于 JTA 的上下文会话即可。
They recommend using JTA transaction support in Java EE environment.
But how to configure JTA in Tomcat6 so that Hibernate Session could use it ?
Starting with version 3.0.1, Hibernate added the
SessionFactory.getCurrentSession()method. Initially, this assumed usage of JTA transactions, where the JTA transaction defined both the scope and context of a current session. Given the maturity of the numerous stand-alone JTA TransactionManager implementations, most, if not all, applications should be using JTA transaction management, whether or not they are deployed into a J2EE container. Based on that, the JTA-based contextual sessions are all you need to use.
(Hibernate Reference Documentation | Architecture. Contextual Sessions)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您希望 Tomcat 支持 JTA，则需要使用独立的事务管理器，例如 Atomikos、JOTM、Bitronix、SimpleJTA、JBossTS 或 GeronimoTM/Jencks。但老实说，如果您不打算跨多个资源处理事务，那么您可以没有 JTA（如果您确实需要 JTA，请使用成熟的应用程序服务器）。
If you want JTA support in Tomcat you'll need to use a standalone transaction manager like Atomikos, JOTM, Bitronix, SimpleJTA, JBossTS or GeronimoTM/Jencks. But honestly, if you're not going to handle transactions across multiple resources, then you can live without JTA (and if you really need JTA, use a full blown application server).
如果您只想使用 SessionFactory.getCurrentSession() ，您只需将以下两行添加到 hibernate.cfg.xml 中即可：
这将为每个线程提供一个唯一的 Session 。由于 Servlet 请求始终在一个线程内处理（假定您的代码不会生成新线程），因此会话将在整个请求期间有效。
不要忘记在请求后使用过滤器关闭会话！
If you just want to use
SessionFactory.getCurrentSession()you can just add the following two lines to your hibernate.cfg.xml:This will give you a unique Session for each thread. As a servlet request is always handled within one thread (given that your code doesn't spawn new ones), the Session will live for the whole request.
Don't forget to use a filter to close the Session after the request!