EJB: éviter la restauration de transaction

Lorsqu'un (transactionnel) méthode d'un EJB appelle une autre (transactionnel) méthode d'un autre EJB, et une exception est levée dans le second, mais piégé dans la première, il semble que la transaction est automatiquement annulée lorsque la seconde renvoie, même si la première attrape, est-ce vrai? comment puis-je l'éviter?

Le scénario est le suivant:

@Stateless
class ClassA {
   @EJB
   ClassB objectB;

   methodA() { 
       try { 
            objectB.methodB(); 
       }
       catch(Exception e) {
            //Here the transaction started in this method is 
            //automatically rolled back. Is this avoidable?
       } 
   }
}

@Stateless
class ClassB {
   methodB() throws Exception { throw new Exception() }
}

source d'informationauteur edutesoy

  1. 19

    De la Transaction est annulée dans le cas où vous jetez un RuntimeException ou toute Exception qui ont @ApplicationException annotation avec rollback attribut truedonc:

    @ApplicationException(rollback=true)
public class MyException extends Exception {
    //...
}

    annulera la transaction en cours.

    Par défaut ApplicationException ne pas rollback de la transaction.

    Si vous ne voulez pas methodB de restauration de votre transaction, vous pouvez modifier le comportement de restauration de votre ApplicationException ou empêcher l'opération de partage.

    Ce dernier est réalisable par la modification de la TransactionAttribute de methodB c'est à dire à RequiresNew. Puis methodA transaction (Tx1) sera suspendend et en cas methodB déclenche une exception qui résultats dans un rollback de la transaction (Tx2), vous pouvez encore attraper dans la methodA et empêcher la restauration de votre methodA transaction (Tx1).

  2. 9

    Oui, c'est vrai, si l'exception est une exception d'exécution. Vérifié les exceptions ne doivent pas entraîner une annulation de la transaction.

    Pour éviter cela, assurez-vous que le code de la methodB ne jette pas tout runtime exception. Une exception d'exécution indique normalement un bug, ou un état qui ne permettait pas de poursuivre le travail.