4 Replies Latest reply on Oct 24, 2003 5:38 AM by Petri Wessman

    Correct way to abort transaction in session bean?

    Petri Wessman Newbie

      Hello all, this is probably a straightforward question but a small amount of RTFM failed to enlighten me.

      If I have a session bean with container-managed transactions (say "Required" for example), what is the correct and portable way to abort the transaction, causing rollback of any referenced entity beans etc? Should I throw a certain type of exception, any type of exception, or manually reference the transaction API?

      For example, currently I have session bean code that looks like this:

      public void doSomething () throws MyOwnException {
      EntitybeanLocal entity = ... (get entity bean);
      (get data, possibly set some other entity data)

      if (!everythingOk) {
      // damn, the data isn't suitable for doSomething,
      // rollback transaction (hopefully)
      throw new MyOwnException("blech, no luck, try again later");
      }
      }

      Is throwing a user-defined exception enough, or should I do something else/more?

      All enlightenment appreciated :)

      //Petri

        • 1. Re: Correct way to abort transaction in session bean?
          Petri Wessman Newbie

          Hmm, nobody?

          I'd have thought that this was close to a FAQ (though I didn't find the answer there :), since automatic transaction management is such a basic part of EJBs. Apparently it's not as common knowledge as I thought. Hmph. Back to RTFM...

          • 2. Re: Correct way to abort transaction in session bean?
            Petri Wessman Newbie

            Addendum: Sun's j2ee blueprints has the following:

            ----
            6. What are some tips for using container-managed transaction demarcation?
            ...
            * Implement rollbacks by calling EJBContext, and then throwing an exception.
            ----

            I assume that refers to calling setRollbackOnly() on the context(?).

            So is the correct j2ee (and/or JBoss) way to do this the following?:

            if (kaboom) {
            context.setRollbackOnly();
            throw new MyOwnException("boom!");
            }

            Or should I throw an instance of EJBException?

            • 3. Re: Correct way to abort transaction in session bean?
              Ivan O. Parra Novice

              Generally, anyone correct me if I'm wrong, you have 2 types of exception. Runtime and application.

              If a runtime exception is thrown and is observed across a app server boundary(proxies), then the transaction is automatically rollback.

              If an application exception is thrown, the appserver will not doing anything to the transaction. It's up to the application to call context.setRollBackOnly().

              EJBException is a standard runtime exception that can be extended to include more information. The transaction should also rollback if a NullPointerException or any other type of runtime exception is caught.

              Answer your question?
              -Ivan

              • 4. Re: Correct way to abort transaction in session bean?
                Petri Wessman Newbie

                ...
                > EJBException is a standard runtime exception that can
                > be extended to include more information. The
                > transaction should also rollback if a
                > NullPointerException or any other type of runtime
                > exception is caught.
                >
                > Answer your question?
                > -Ivan

                Yes, thanks, it confirms what I've read elsewhere.

                So apparently there are two ways of doing this:

                a) throw EJBException or some other "system" exception, this will cause rollback automatically.

                b) call context.setRollbackOnly(), then throw your own (application) exception.

                Which one is more suitable for you depends on the application, and on whether you want to wrap eveything as EJBExceptions.