5 Replies Latest reply on Jul 8, 2003 9:12 AM by krichards

    Transaction scope with Session beans, flat classes and Entit

    krichards

      Hi,

      We are using a stateless Session EJB to invoke execute methods on flat "command" java classes, these classes in turn use several Entity beans.

      I would assume that if my Session EJB creates a new Transaction context on it's invoke method, and presuming I put the correct transaction settings in the deployment descriptors for the entity beans, then I will have one transaction scope for the duration of the execute method on the command class, and any exceptions will trigger rollbacks.

      Does this sound correct? I've run this past a couple of other guys and they have said that this won't work. But I can't get a good answer why? Can anyone help me out?

        • 1. Re: Transaction scope with Session beans, flat classes and E
          strathound

          Are you using Container managed transactions (transactions, not persistence) or User mananaged? If the former, then the transaction boundary is the EJB method invocation. For instance, if your session bean has a "foo()" method, the transaction would begin when the "foo()" method is called and ends when it returns. That means that all things the container knows about during that invocation are transaction aware. We use this to encompass both database and JMS events in our session beans. It all commits or it all rolls back.

          In the case of user managed transactions, you set the transaction boundaries, so it's completely configurable. But you are responsible for beginning and ending the transactions. Don't goof it up. :)

          HTH,

          Michael

          • 2. Re: Transaction scope with Session beans, flat classes and E
            haraldgliebe

            Hi,

            the transaction is associated with the current thread of control, therefore it doesn't matter if you are calling the entity bean directly from the session bean or via some java classes.

            Regards,
            Harald

            • 3. Re: Transaction scope with Session beans, flat classes and E
              krichards

              Thanks - The Session bean, and all the entity beans are container managed. I've checked my deployment descriptors and they seem to be okay, but I still get exceptions passed back from an EJB that don't cause a rollback.

              At the moment I just have it set up so that one of my Entity beans has a null PK, so it always throws and EJBException on creation.

              In rough form the code looks like

              public class CommandEngineEJB implements SessionBean {

              public CommandResultIF execute(Command cmd) {
              return cmd.execute();
              }
              }


              public Class exampleCmd() extends Command {
              public CommandResultIF execute() {
              // EJB calls
              cntx = new InitialContext();
              UserAccountLocalHome userlocalhome = (UserAccountLocalHome) cntx.lookup(UserAccountLocalHome.JNDI_NAME);
              UserAccountLocal user = userlocalhome.create(null);

              }
              }

              And a snippet from the jboss deployment descriptor looks like ...
              ...
              <container-transaction >

              <ejb-name>CommandEngine</ejb-name>
              <method-name>*</method-name>

              <trans-attribute>Required</trans-attribute>
              </container-transaction>
              ...

              And the entity beans all have similar settings .....

              Am I being really dumb?

              Kev

              • 4. Re: Transaction scope with Session beans, flat classes and E

                Only RuntimeException, Error and RemoteException force
                a rollback, you must setRollBackOnly() on the bean context
                if you want other Exceptions to rollback the transaction.

                Regards,
                Adrian

                • 5. Re: Transaction scope with Session beans, flat classes and E
                  krichards

                  Thanks I just figured that out!!! So the correct answer was of course -- yes you are being dumb!!

                  Thanks all

                  Kev