JTA (EJB-- Store Procedure) Problem

Question

I'm currently facing a problem that I'm not sure how to fix it.
          I have a Controller class that is accessing many EJB (Session Stateless Container Managed) that are a kind of Store Procedures' Wrappers.
          The Controller initializes the transaction using the UserTransaction and it commits or rollback as needed, also de EJBs at some points use the setRollbackOnly() and also inside the store procedures are some explicit commits.
          What should I expect in the following scenario:
          UserTransaction ut=null;
          try {
          ut = getUserTransaction();
          ut.begin();
          ejb1.update(); //Calls a store procedure that in the pl/sql calls commit
          ejb2.delete(); //Inside the Ejb some component throws an exception and is catched by the Ejb, then it calls setRollbackOnly() and throws a new Exception
          ut.commit();//This is not called because the previous exception
          } catch(Exception e){
          ut.rollback();//Rollback is called
          1) Is the modified data inside ejb1.update saved?
          2) Is this all wrong?
          3) What could it be a right approach to refactor this?
          Thanks,
          Johann

Answer 1

johann renck wrote:
          > There is one store proc who cares about logging that is called by many others sp that
          > is the one who does commit and also is wrapped by an Ejb so it is also called inside
          > the application. Have this sp its own transaction context so when it does commit it
          > just commits the logging?
          >
          > Thanks,
          > Johann
          Yes, always. Any procedure that calls begin tran, commit, rollback, or any other call that
          changes the transactional behavior of the session, must be isolated from everything that
          WebLogic thinks is part of a transaction. Otherwise you're just going to jeopardize the
          integrity of your WebLogic-defined transactions. Ideally, you want all your transactions
          defined and controlled at one level. From the EJB/WebLogic point of view it would be much
          safer and superior to never call any procedure that had such stuff, and then do logging
          as it's own WLS EBJ tx, called everywhere needed, from within but separate from larger EJB
          transactions. Even if a logging EJB did nothing besides writing one log row, the procedure
          shouldn't call commit. The EJB system will do that.
          Note well: Anything that calls that logging procedure with the commit, commits it's
          current possibly partial transaction to that point. The DBMS connection only has one
          transaction going on at a time, and a commit permanently locks in everything changed since
          the last commit. It is not good architecture to have commits in any utility procedure.
          At the very least, if your procedures want a transaction, they should start and end
          in one procedure, eg:
          BEGIN
               declare boolean variable in_tx
          set in_tx true if @@trancount > 0
               if (not in_tx) BEGIN TRAN -- Otherwise, just become part of current tx
               ... do work... this is only needed for multi-update work
          if (not in_tx) COMMIT TRAN
          END
          If the procedure only does one update/insert/delete *you don't need any
          tx control*! eg:
          BEGIN
               insert into mylogtable values (.....)
          END
          That one insert will be part of any ongoing tx if extant, or
          will be it's own one auto-commit tx.
          If you have a procedure that must be it's own tx, then you must
          do:
          BEGIN
               if (@@trancount > 0) raiserror("Can't call this procedure from an ongoing transaction. It must be able to commit immediately")
          END