5 Replies Latest reply on May 3, 2002 3:32 PM by Duarte Loreto

    Transaction management with partial rollback (using UserTran

    Duarte Loreto Newbie


      I have a problem and I need some help. I have this situation. I have an EJB (Session Stateless) that starts a transaction (using UserTransaction) and then calls three other EJBs.

      All three EJBs are Session Stateless and join the "father" transaction (<trans-attribute>required</trans-attribute>).

      If the 1st or 3rd give an error, I want to rollback the whole transaction. That is easy. But if the 2nd gives an error, I would like to proceed with the transaction, but doing a rollback on the specific inserts/updates done by the 2nd EJB.

      The transaction is done over Oracle 8 database with JDBC Oracle classes.

      Can anyone tell me how can I, after EJB 1 does his work sucessfully and EJB 2 blows up, rollback EJB2 stuff maintaing EJB1 stuff on the transaction so that if EJB3 blows up I can rollback EJB1 along with EJB3, or if EJB3 goes well, commit both EJB1 and 3 without having partial stuff from EJB2 commited?

      Thank you very much for your time!


        • 2. Re: Transaction management with partial rollback (using User
          David Jencks Master

          You'd need savepoints which are not part of the jta transaction model. You might possibly be able to do this with a driver supporting savepoints and bmp and controlling transactions directly through the driver, not through userTransaction.

          I would very strongly recommend you redesign what you are doing so you stop wanting this feature.

          • 3. Re: Transaction management with partial rollback (using User
            Duarte Loreto Newbie

            Hello, again!

            First of all, many thanks for replying me!

            OK. So now I understand that I shouldn't be wanting what I want. So, in order to redesign, I need some help on how to do it. I'll be describing what I want, maybe someone can give some thoughs on this.

            Lets say that I have a bank management app. I have one EJB that creates the account, one that creates the customer and one that adds the new customer to a mailing list and sends him a welcome SMS to his celular.

            I want to call, on the same transaction, the three EJBs (all stateless session beans). If the customer or account creation fail, I want to rollback the whole transaction.

            But if the mail registration and SMS sending fail, I want to be able to rollback this but commit the other two beans. This is considered an "optional" bean that can run later called by a reprocessor mechanism.

            The only way I imagine this possible is by executing first all beans that MUST give sucess. If all goes well, commit and then execute the "optional" beans, each one in his own transaction, obtaining this way the necessary transaction isolation.

            Is this the best approach or does anyone have a better idea?

            Thank you again for your time!


            • 4. Re: Transaction management with partial rollback (using User
              David Jencks Master

              Think about the time scale. The first 2 actions have to happen immediately. The spam signup (sorry, I couldn't resist;-) can happen at any time later, you just want to guarantee that it happens eventually.

              Use transacted jms for the spam sign up: your original session bean's signup method has tx Required, it created entities A and B and posts a sign-up message to a (durable) queue all in the same transaction.

              The jms services will attempt to deliver the message repeatedly: if it fails too many times, it will go into a dead letter queue (DLQ) that you can examine manually.

              You can do something more like you propose by using more transactions: however I think it will have slightly different and perhaps less desirable semantics.

              • 5. Re: Transaction management with partial rollback (using User
                Duarte Loreto Newbie


                Thank you for you reply! We will work on the JMS solution. It seems a lot cleaner that the one we were thinking of.

                The best for you! :)