5 Replies Latest reply: Jun 13, 2010 11:58 PM by 800389 RSS

    Distributed and Nested Transactions

    807580
      It seems JTA supports transactions distributed across multiple EJBs, but does not allow nested transactions.
      So what is the purpose of the @TransactionAttribute(REQUIRES_NEW) annotation since rolling back its transaction has no effect on the parent transaction?
        • 1. Re: Distributed and Nested Transactions
          800389
          ADJavaUser wrote:
          So what is the purpose of the @TransactionAttribute(REQUIRES_NEW) annotation since rolling back its transaction has no effect on the parent transaction?
          This IS the purpose of REQUIRES_NEW. In many cases you want your called bean to commit the transcation unconditionally. So, EJB has given a way to do this. Here is the statement from blueprint.

          The RequiresNew transaction attribute is useful when the bean method needs to commit unconditionally, whether or not a transaction is already in progress. An example of this requirement is a bean method that performs logging. This bean method should be invoked with the RequiresNew transaction attribute so that logging records are created even if the calling client's transaction is rolled back.

          If you want your parent transaction to be roll back, you can use other transaction attribute required/supports etc.
          • 2. Re: Distributed and Nested Transactions
            807580
            What if I want to roll back the parent transaction if the child transaction fails?
            • 3. Re: Distributed and Nested Transactions
              800389
              ADJavaUser wrote:
              What if I want to roll back the parent transaction if the child transaction fails?
              There are two ways to roll back a container-managed transaction. First, if a system exception is thrown, the container will automatically roll back the transaction. Second, by invoking the setRollbackOnly method of the EJBContext interface, the bean method instructs the container to roll back the transaction. If the bean throws an application exception, the rollback is not automatic, but may be initiated by a call to setRollbackOnly.
              • 4. Re: Distributed and Nested Transactions
                807580
                Yes, but if there are no nested transactions and a new transaction is started using REQUIRES_NEW after a method invocation, if I invoke setRollbackOnly() wouldn't it only rollback the most recent transaction?

                E.g. MethodOne() starts a transaction and invokes MethodTwo which has its own REQUIRES_NEW transaction attribute. Doesn't MethodOne's transaction get suspended and a new transaction started for MethodTwo? So if setRollBackOnly() is invoked in MethodTwo, wouldn't that only rollback the transaction for MethodTwo - and not also the first (suspended) parent transaction for MethodOne?

                If so, then this is not the equivalent of a nested transaction in which a failed child transaction can be detected by the parent transaction and either re-run or terminate the parent transaction as well.
                • 5. Re: Distributed and Nested Transactions
                  800389
                  ADJavaUser wrote:
                  Yes, but if there are no nested transactions and a new transaction is started using REQUIRES_NEW after a method invocation, if I invoke setRollbackOnly() wouldn't it only rollback the most recent transaction?
                  Yes. It is correct however as mentioned in reply#1, if you want to plug the parent and child transaction you shouldn't use the REQUIRES_NEW.

                  And still if you want to do it, you have to provide some sort of child bean output check, if you child bean successfully commits the data, it will be reflected in DB and when you do cross check in parent bean, you will find the updated data. And if the data is not as expected, it means child transaction has not successfully committed and you should then rollback the parent transaction.

                  I don't know in what scenario you require this however I would suggest revisiting the scenario.