当容器管理的 tx EJB 提交时，如何捕获和包装 JTA 抛出的异常？

Question

我正在努力解决管理非平凡数据模型的 EJB3 类的问题。当我的容器管理的事务方法提交时，我抛出了约束验证异常。我想防止它们被包裹在EJBException 中，而是抛出一个调用者可以处理的合理的应用程序异常。

要将其包装在合适的应用程序异常中，我必须能够捕获它。大多数时候，一个简单的 try/catch 就可以完成这项工作，因为验证异常是从我进行的 EntityManager 调用中引发的。

不幸的是，某些约束仅在提交时检查。例如，映射集合上的@Size(min=1) 违规只有在容器管理的事务提交时才会被捕获，一旦它在我的事务方法结束时离开我的控制。我无法捕获验证失败时引发的异常并将其包装，因此容器将其包装在javax.transaction.RollbackException 中并将that 包装在受诅咒的EJBException 中。调用者必须捕获所有 EJBExceptions 并深入原因链以尝试找出它是否是一个验证问题，这真的不好。

我正在处理容器管理的事务，所以我的 EJB 如下所示：

@Stateless
@TransactionManagement(TransactionManagementType.CONTAINER
class TheEJB {

    @Inject private EntityManager em;

    @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
    public methodOfInterest() throws AppValidationException {
       try {
           // For demonstration's sake create a situation that'll cause validation to
           // fail at commit-time here, like
           someEntity.getCollectionWithMinSize1().removeAll();
           em.merge(someEntity);
       } catch (ValidationException ex) {
           // Won't catch violations of @Size on collections or other
           // commit-time only validation exceptions
           throw new AppValidationException(ex);
       }
    }

}

... 其中AppValidationException 是已检查异常或未检查异常，注释为@ApplicationException，因此它不会被EJB3 包装。

有时我可以使用EntityManager.flush() 触发早期约束违规并抓住它，但并非总是如此。即便如此，我真的也希望能够在提交时捕获由延迟约束检查引发的数据库级约束违规，并且这些只会在 JTA 时出现永远提交。

帮助？

---

已经尝试过：

Bean 管理的事务 将通过允许我在我控制的代码中触发提交来解决我的问题。不幸的是，它们不是一个选项，因为 bean 管理的事务不提供任何等效的 TransactionAttributeType.REQUIRES_NEW - 没有办法使用 BMT 暂停事务。 JTA 令人讨厌的疏忽之一。

见：

• Why we need JTA 2.0
• Bean-Managed Transaction Suspension in J2EE（不要这样做！）

...但请参阅注意事项和详细信息的答案。

javax.validation.ValidationException 是 JDK 异常；我无法修改它以添加 @ApplicationException 注释 以防止包装。我不能子类化它来添加注释；它是由 EclpiseLink 抛出的，而不是我的代码。我不确定将其标记为 @ApplicationException 是否会阻止 Arjuna（AS7 的 JTA impl）将其包装在 RollbackException 中。

我尝试像这样使用 EJB3 拦截器：

@AroundInvoke
protected Object exceptionFilter(InvocationContext ctx) throws Exception {
    try {
        return ctx.proceed();
    } catch (ValidationException ex) {
        throw new SomeAppException(ex);
    }
}

...但似乎拦截器在内部 JTA（这是明智的，通常是可取的）触发，所以我想要捕获的异常还没有被抛出。

我想我想要的是能够定义一个在 JTA 完成它的事情之后应用的异常过滤器。有什么想法吗？

---

我正在使用 JBoss AS 7.1.1.Final 和 EclipseLink 2.4.0。 EclipseLink 根据these instructions 安装为 JBoss 模块，但这对于手头的问题并不重要。

---

更新：在对这个问题进行了更多思考之后，我意识到除了 JSR330 验证异常之外，我真的还需要能够从 DB 中捕获 SQLIntegrityConstraintViolationException 和 deadlock or serialization failure rollbacks with SQLSTATE 40P01 and 40001 respectively .这就是为什么试图确保提交永远不会抛出的方法不会很好地工作的原因。已检查的应用程序异常不能通过 JTA 提交抛出，因为 JTA 接口自然不会声明它们，但未检查的 @ApplicationException 注释异常应该可以。

似乎在任何我可以有效地捕获应用程序异常的地方，我也可以 - 尽管不那么漂亮 - 捕获 EJBException 并深入研究 JTA 异常和底层验证或 JDBC 异常，然后基于此做出决策。如果没有 JTA 中的异常过滤器功能，我可能不得不这样做。

Answer 1

我在原始问题中所说的 REQUIRES_NEW 和 BMT 有一个警告。

参见 EJB 3.1 规范，13.6.1Bean-Managed Transaction Demarcation 部分，容器职责。上面写着：

容器必须管理对企业 bean 的客户端调用 具有 bean 管理的事务划分的实例如下。当一个 客户端通过企业 bean 的一个调用业务方法 在客户端视图中，容器会暂停任何可能发生的事务 与客户端请求相关联。 如果有交易 与实例相关联（如果有状态会话会发生这种情况 bean 实例在之前的某个业务中启动了事务 方法），容器将方法执行与此相关联 交易。如果有与 bean 关联的拦截器方法 实例，这些操作是在拦截器方法之前执行的 调用。

（斜体我的）。这很重要，因为这意味着 BMT EJB 不会继承具有关联容器管理 tx 的调用者的 JTA tx。任何当前的 tx 都暂停，因此如果 BMT EJB 创建一个 tx，它就是一个 新 事务，当它提交时，它只提交它的事务。

这意味着您可以使用 BMT EJB 方法开始并提交事务，就好像它实际上是 REQUIRES_NEW 并执行以下操作：

@Stateless
@TransactionManagement(TransactionManagementType.BEAN)
class TheEJB {

    @Inject private EntityManager em;

    @Resource private UserTransaction tx; 

    // Note: Any current container managed tx gets suspended at the entry
    // point to this method; it's effectively `REQUIRES_NEW`.
    // 
    public methodOfInterest() throws AppValidationException, SomeOtherAppException {
       try {
           tx.begin();
           // For demonstration's sake create a situation that'll cause validation to
           // fail at commit-time here, like
           someEntity.getCollectionWithMinSize1().removeAll();
           em.merge(someEntity);
           tx.commit();
       } catch (ValidationException ex) {
           throw new AppValidationException(ex);
       } catch (PersistenceException ex) {
           // Go grubbing in the exception for useful nested exceptions
           if (isConstraintViolation(ex)) {
               throw new AppValidationException(ex);
           } else {
               throw new SomeOtherAppException(ex);
           }
       }
    }

}

这将提交置于我的控制之下。在我不需要事务来跨越多个不同 EJB 的多个调用的情况下，这允许我在我的代码中处理所有错误，包括提交时的错误。

Java EE 6 tutorial page on bean managed transactions 没有提及这一点，也没有提及如何调用 BMT。

我链接到的博客中关于 BMT 无法模拟 REQUIRES_NEW 的说法是有效的，只是不清楚。如果您有一个 bean 管理的事务 EJB，则您不能暂停一个您已开始的事务 以开始另一个事务。调用单独的帮助程序 EJB 可能会暂停你的 tx 并给你相当于 REQUIRES_NEW 但我还没有测试过。

---

问题的另一半——在我需要容器管理事务的情况下，因为我必须跨多个不同的 EJB 和 EJB 方法完成工作——通过防御性编码来解决。

实体管理器的早期急切刷新允许我捕获我的 JSR330 验证规则可以找到的任何验证错误，因此我只需要确保它们是完整和全面的，这样我就不会收到任何检查约束或完整性违规错误提交时的数据库。我不能干净地处理它们，所以我需要真正防御性地避开它们。

防御性编码的一部分是：

• 在实体字段上大量使用javax.validation 注释，并在这还不够的情况下使用@AssertTrue 验证方法。
• 我很高兴看到集合的验证约束得到支持。例如，我有一个实体A，其集合为B。 A 必须至少有一个 B，所以我在B 的集合中添加了一个@Size(min=1) 约束，它在A 中定义。
• 自定义 JSR330 验证器。我为澳大利亚商业号码 (ABN) 等内容添加了几个自定义验证器，以确保我永远不会尝试向数据库发送无效验证器并触发数据库级验证错误。
• 使用EntityManager.flush() 提前刷新实体管理器。这会强制验证在您的代码控制下进行，而不是在 JTA 提交事务时进行。
• 我的 EJB 外观中的特定于实体的防御代码和逻辑，以确保不会出现 JSR330 验证无法检测到的情况并导致提交失败。
• 在可行的情况下，使用 REQUIRES_NEW 方法强制提前提交并允许我处理 EJB 中的故障、适当地重试等。这有时需要帮助 EJB 来解决自调用业务方法的问题。李>

我仍然无法像在 Swing 中直接使用 JDBC 那样优雅地处理和重试序列化失败或死锁，因此容器提供的所有这些“帮助”使我在某些方面倒退了几步。不过，它在其他地方节省了大量繁琐的代码和逻辑。

在发生这些错误的地方，我添加了一个 UI 框架级别的异常过滤器。它看到 EJBException 包装了 JTA RollbackException 包装了 PersistenceException 包装了 EclipseLink 特定的异常包装了 PSQLException，检查了 SQLState，并根据它做出决定。这是荒谬的迂回，但它有效

Answer 2

我没试过这个。但我猜这应该可行。

@Stateless
@TransactionManagement(TransactionManagementType.CONTAINER)
class TheEJB {

    @Inject
    private TheEJB self;

    @Inject private EntityManager em;

    public methodOfInterest() throws AppValidationException {
       try {
           self.methodOfInterestImpl();
       } catch (ValidationException ex) {
           throw new AppValidationException(ex);
       }
    }

    @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
    public methodOfInterestImpl() throws AppValidationException {
        someEntity.getCollectionWithMinSize1().removeAll();
        em.merge(someEntity);
    }    
}

容器应该启动一个新事务并提交在methodOfInterest，因此您应该能够在包装器方法中捕获异常。

Ps：答案是根据@LairdNelson 提供的优雅想法更新的...

Answer 3

将eclipselink.exception-handler 属性设置为指向ExceptionHandler 的实现看起来很有希望，但没有成功。

ExceptionHandler 的 JavaDoc 是……糟糕……所以您需要查看 test implementation 和使用它的测试（1、2）。还有一些更有用的文档here。

似乎很难使用异常过滤器来处理一些特定情况，同时不影响其他所有情况。我想捕获PSQLException，检查 SQLSTATE 23514（CHECK 约束违规），为此抛出一个有用的异常，否则不会更改任何内容。这看起来不太实用。

最后，我放弃了这个想法，尽可能使用 bean 托管事务（现在我正确理解了它们的工作原理）和一种防御方法，以防止在使用 JTA 容器托管事务时出现不需要的异常。

Answer 4

javax.validation.ValidationException 是 JDK 异常；我不能 修改它以添加 @ApplicationException 注释以防止 包装

除了您的答案：您可以使用 XML 描述符将 3rd 方类注释为 ApplicationException。