JPA事务是否一定要在EJB中？
我试图编写一个DAO类并使用该类中的EntityManager来执行持久操作。我的数据库在我的persistence.xml中定义为jta-data-source，并相应地在我的Web应用程序服务器中注册为数据源。
因此，在我的DAO中使用EntityManager的em.persist（）方法时遇到了一个问题，因为我需要一个事务。显然，它必须是一种称为UserTransaction的特殊类型的事务。
在Web中搜索示例，我发现您可以使用@Resources UserTransaction utx注入此事务；
但是为了使注入工作，我的DAO类必须由容器初始化，使其成为EJB（@Stateless）。使我的DAO容器受管理会阻止我自由地手动初始化DAO类。
如何在DAO类中创建事务而不使其成为EJB？我必须手动在JNDI中查找UserTransaction吗？
共有1个答案
在JavaEE中，您的DAO确实应该由容器（服务器）管理。只有托管的组件才能完全访问JavaEE规范中指定的资源和上下文。例如，单个事务可以在一次调用期间由许多组件共享，因此服务器需要管理这些组件的生命周期并控制它们的状态。
如果您使用@State注释您的DAO，您将进入无状态会话Bean-即EJB bean，默认情况下是事务感知的。您不必使用EJB-例如，您可以使用CDI@Transactional，但EJB确实是数据访问层的理想构建块。
尝试花一些时间阅读官方的JavaEE教程，或查看大量JavaEE示例项目，以更好地了解如何为JavaEE开发。
-
我在这里很困惑。JPA中的提交或回滚完成事务吗？我使用的是spring和容器管理的EntityManager。感谢任何回答。
-
这是一个配置JPA和使用JTA事务模式连接数据库的简单指南。此外，它还包括开发人员最常见的错误，您应该避免这些错误。希望这对你有帮助。
-
问题内容： 那里的许多示例都主张对数据库事务进行显式回滚，具体方法如下： 但是，我倾向于这样做： 当发生异常时，我只是依靠未提交事务的隐式回滚。 依靠这种隐式行为有什么问题吗？有人有令人信服的理由为什么我不应该这样做吗？ 问题答案： 不，它不是特别需要的，但是我可以想到两个可能是个好主意的原因： 明晰 有人可能会争辩说使用可以更清楚地表明在什么情况下不会进行交易。 释放锁 在处理事务时，重要的是要
-
我在存储库类中有一个方法，标记为，该方面正在执行，如stacktrace中所示，但抛出的异常是“Transaction required exception” 电磁场： 交易： 我真的要疯了，任何帮助都会很好。 似乎，有一个事务，它被检查为完成，加入事务失败，所以它标记为仅回滚，因为它不能加入它。
-
这是请求 我试图在我的应用程序中使用上面的ejb 1） 包含JDBC语句2018-03-27 16:28:17,683:错误:http-nio-6180-exec-1:BatchingBatch.PerformExecution:HHH000315:Exception执行批处理[java.sql.BatchUpdateException：batch entry 0 insert into TEAM
-
问题内容： Java EE7由一堆“ bean”定义组成： 托管Beans 1.0（JSR-316 / JSR-250） Java 1.0的依赖注入（JSR-330） CDI 1.1（JSR-346） JSF托管Beans 2.2（JSR-344） EJB 3.2（JSR-345） 为了摆脱头脑中的混乱，我研究了几篇“何时使用哪种bean类型”的文章。 EJB 的优点之一似乎是 它们仅支持声明式容