了解EJB3 / JPA容器级事务和隔离级别

Question

考虑一下我正在使用的一些代码的简化视图：

@Stateless(...)
@Remote(...)
@TransactionAttribute(TransactionAttributeType.MANDATORY)
public class FirstEjbType {

   @EJB(...)
   private SecondEjbType secondEjb;
   @EJB(...)
   private ThirdEjbType thirdEjb;

   public void doSomething() {
      secondEjb.doSomething();  // WRITES SOMETHING TO THE DATABASE
      thirdEjb.doSomething();  // CAN'T SEE THAT SOMETHING IN THE DATABASE!
}

我已经在类级别将TransactionAttribute注释设置为MANDATORY 。 我理解这意味着必须在提供的事务中调用所有方法，如doSomething() 。 在这种情况下，我们使用容器管理的事务。

在SecondEjbType或ThirdEjbType中SecondEjbType不使用TransactionAttribute ......在类和方法级别都没有。 我理解这意味着secondEjb.doSomething()和thirdEjb.doSomething()都将在为firstEjb.doSomething()提供的事务中运行。

但是，我真的错过了什么 ！ 如代码注释所示... secondEjb将数据写入数据库， thirdEjb将该数据作为其操作的一部分进行读取。 由于所有这些都在同一个事务中运行，我不希望隔离级别存在任何问题。 但是，无论出于何种原因， secondEjb数据库写入对thirdEjb不可见。

我已经将跟踪一直转到最大值，并且显然没有异常或错误或回滚问题......初始写入对于后续读取是不可见的。 我并不认为自己是交易管理方面世界上最伟大的大师...我是否错过了一些明显的东西，或者我的概念理解基本正确，问题可能在其他地方？

---

更新 - 约翰斯托克要求的其他信息如下：

• 我在GlassFish中运行
• 我不确定你的意思是“非标准冲洗模式”，所以我认为答案是否定的。
• 我的persistence.xml文件如下所示：

<persistence xmlns="http://java.sun.com/xml/ns/persistence" version="1.0">
<persistence-unit name="pu" transaction-type="JTA">
<jta-data-source>jdbc/datasource</jta-data-source>
<exclude-unlisted-classes>false</exclude-unlisted-classes>
<properties>
<property name="toplink.cache.shared.default" value="false"/>
</properties>
</persistence-unit>
</persistence>

Answer 1

要检查的第一件事是bean 2和3使用@PersistenceContext EntityManager获取EntityManager而不是 @PersistenceUnit EntityManagerFactory后跟createEntityManager()调用。

其次，检查DataSource是否实际设置为参与JTA事务（autoCommit或相关属性应该关闭）。

最后，检查传播的快速而脏的方法是调用EntityManager.getDelegate()方法并检查结果对象在整个预期事务范围内是否相同 。

这里的内容是如何工作的......在创建bean时，注入到bean中的EntityManager是一个假的，简单的外观。 当您尝试在事务中使用EntityManager引用时，容器将实际挖掘当前事务，找到在事务范围中存储的真实 EntityManager并将您的调用委托给该 EntityManager（如果已经没有EntityManager）事务，容器将创建一个并添加它）。 这个真实对象将是getDelegate()的值。 如果getDelegate()的值在secondEjb.doSomething()和thirdEjb.doSomething()不相同（==），那么您没有获得预期的传播，并且每个都在与不同的持久化上下文进行通信。

另外，请注意，在类上应用MANDATORY实际上只影响在该类中定义的方法，而不是在超类中。 如果未在超类上指定@TransactionAttribute，则无论子类如何注释，这些方法都使用默认值。 我只提到它，因为它可能会影响您对代码的理解。

Answer 2

我已经在类级别将TransactionAttribute注释设置为MANDATORY。 我理解这意味着必须在提供的事务中调用所有方法，如doSomething（）。 在这种情况下，我们使用容器管理的事务。

在类级别使用MANDATORY意味着如果在调用任何FirstEjbType方法时没有正在进行的事务，容器应该向调用者抛出异常。

出于好奇，谁开始交易呢？ 有没有特别的理由不使用默认的REQUIRED ？

在SecondEjbType或ThirdEjbType中根本不使用TransactionAttribute ......在类和方法级别都没有。 我理解这意味着secondEjb.doSomething（）和thirdEjb.doSomething（）都将在为firstEjb.doSomething（）提供的事务中运行

这意味着使用了默认事务属性，即REQUIRED ，并且保证在事务中执行REQUIRED方法（ 如果需要，容器将启动一个）。

所以在你的情况下， secondEjb.doSomething()和thirdEjb.doSomething()应该确实在firstEjb.doSomething()的事务中执行。

我错过了一些明显的东西，或者我的概念理解是否基本正确，问题可能在其他地方？

（事务范围）持久性上下文传播的经验法则是持久化上下文在JTA事务传播时传播。 但是有一些限制。 JPA规范如下：

5.6.3持久性上下文传播

如5.1节所述，单个持久化上下文可以对应于一个或多个JTA实体管理器实例（全部与同一实体管理器工厂相关联）。

随着JTA事务的传播，持久化上下文在实体管理器实例中传播。

持久化上下文的传播仅适用于本地环境。 持久性上下文不会传播到远程层。

Sahoo（来自GlassFish团队）更明确地描述了持久化上下文传播中的传播规则：

3.（规则＃3）即使远程EJB恰好在同一个JVM或同一个应用程序的一部分中运行，也不要指望在调用远程EJB时传播PC。

因此，假设您在任何地方使用JPA，我希望在同一事务中调用的业务方法只有在您不使用Remote接口时才会继承相同的持久性上下文（我不知道这是否是GlassFish特定的解释规范，但Sahoo非常清楚这种限制）。

PS：JPA假设一个READ_COMMITTED隔离级别（因此乐观锁定可以工作），标准JPA不允许自定义隔离级别设置（好吧，一些提供商允许全局或按请求更改它，但这是不可移植的）。

PPS： 我不相信隔离级别是你问题的关键。

参考

• JPA 1.0规范
  • 第5.6.3节“持久性上下文传播”

Answer 3

由于标签中提到了jpa ，我想在调用thirdEjb方法之前不会刷新持久化上下文，因此更改不会写入数据库。

默认情况下，JPA持久性上下文在提交之前，执行JPA查询之前或使用em.flush()手动刷新。 因此，更改的可见性取决于thirdEjb使用的数据访问方法 - 如果读取数据（例如，使用JDBC），则在没有em.flush()情况下不应显示更改。

Answer 4

您需要提供更多信息才能回答此问题。

• 您是否在Java EE容器中运行？
• 您是否设置了非标准冲洗模式？
• 你可以发布你的persistence.xml文件吗？

请注意，“持久性上下文”和事务生命周期可能不一样。

交易

根据EJB 3.0，所有EJB 3.0应用程序的缺省事务属性都是REQUIRED 。 交易类型的文档位于： http ： //download.oracle.com/javaee/6/api/javax/ejb/TransactionAttributeType.html

您是否正在使用REQUIRES_NEW交易类型，该交易类型将在单独的交易中运作？

特别是，尝试使用本地而不是远程接口来实现第二个和第三个EJB 。

法拉盛

使用默认设置，在查询之前强制刷新（如果需要）以确保结果正确： http ： //download.oracle.com/javaee/5/api/javax/persistence/FlushModeType.html

尝试调用entityManager.setFlushMode(FlushModeType.AUTO); 确保在查询之前发生刷新。 在JPA提供程序中启用SQL日志记录，以确保在选择之前确实将更新/插入发送到数据库。

Answer 5

我从这里的所有答案中学到了很多，并且不能感谢别人。 但是，我相信我的问题已经使水域变得混乱，以至于可能更好地重新开始一个不同的问题。

看起来从一个EJB跳到下一个EJB并没有与任何事情有关。 为简化问题，我尝试使用完全隔离到一个EJB的测试用例。 我进入了secondEjb.doSomething()方法，该方法将实体持久化到数据库。 在方法结束时，我添加了一个em.flush() ，并尝试使用JPA查询再次检索实体。

即使我仍然使用刚刚保持实体的完全相同的方法 ，但后续查询不可见。 我在其他地方做了一些额外的研究 ，看起来这可能只是JPA在事务环境中的正常隔离模式。 启动一个事务，该事务中的其他查询尚未查看未提交的数据。

如果我对链接的CodeRanch讨论的总结是准确的，那么在JPA上“yuck”！ :)无论哪种方式，我都重构了代码以完全避免这个问题。