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

EN

我还没试过这个。但我猜这应该能行得通。

@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提供的优雅想法而更新的……

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

请参阅容器责任中的EJB3.1规范，13.6.1节spec管理的事务界定。它写道：

容器必须管理客户端对具有bean管理的事务划分的企业bean实例的调用，如下所示。当客户端通过企业bean的客户端视图之一调用业务方法时，容器将挂起可能与客户端请求相关联的任何事务。如果存在与该实例相关联的事务(如果有状态会话bean实例在以前的某个业务方法中启动了该事务，则会发生这种情况)，容器会将该方法的执行与该事务相关联。如果有与bean实例相关联的拦截器方法，则在调用拦截器方法之前执行这些操作。

(斜体我的)。这一点很重要，因为这意味着BMT EJB不会继承具有关联容器托管tx的调用方的JTA tx。任何当前的tx都被挂起，因此如果BMT EJB创建了一个tx，那么它就是一个新事务，当它提交时，它只提交它的事务。

这意味着您可以使用BMT方法开始和提交事务，就好像它是有效的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，那么您不能为了开始另一个事务而挂起一个已经开始的事务。调用单独的helper EJB可能会挂起您的tx，并为您提供等同于REQUIRES_NEW的服务，但我还没有测试过。

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

实体管理器的早期紧急刷新允许我捕获我的JSR330验证规则可以发现的任何验证错误，所以我只需要确保它们是完整和全面的，这样我就不会在提交时从数据库获得任何检查约束或完整性冲突错误。我不能干净利落地处理它们，所以我真的需要防御性地避免它们。

防御性编码的一部分是：

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

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

在发生这些错误的地方，我添加了一个UI框架级别的异常过滤器。它看到EJBException包装JTA RollbackException包装PersistenceException包装特定于EclipseLink的异常包装PSQLException，检查SQLState，并基于此做出决策。这很荒谬，但却很管用

将eclipselink.exception-handler属性设置为指向ExceptionHandler的实现看起来很有希望，但却行不通。

ExceptionHandler的JavaDoc是...坏的..。因此，您需要查看test implementation和使用它的测试(1、2)。还有一些更有用的文档here。

似乎很难使用异常筛选器来处理一些特定的情况，而不影响其他所有情况。我想捕获PSQLException，检查SQLSTATE 23514 (违反CHECK约束)，抛出一个有用的异常，否则不会改变任何东西。这看起来不切实际。

最后，我放弃了这个想法，在可能的情况下转而使用bean管理的事务(现在我正确地理解了它们是如何工作的)，并采用了一种防御性的方法来防止在使用JTA容器管理的事务时出现不必要的异常。