1 Reply Latest reply on Oct 7, 2003 5:42 AM by Darran Lofthouse

    Correct use of UserTransaction in webapp?

    Simon Godden Newbie

      We're using local interfaces from the webapp so that we can more easily make use of CMR.

      Using this pattern, we have to get our usage of UserTransactions right. This is something we haven't been able to get a feel for, whether we are doing it right or fundamentally missing the point in some way.

      One issue with the use of UserTransactions is knowing whether someone else already started one (we have quite a flexible system, where user interface components could be used in different sequences). So we try to deal with that.

      What do you think to the following code? Really, rip it to bits :-)

      UserTransaction ut=null;

      try {
      ut=UiUtil.getUserTransaction();

      try {
      ut.begin();
      } catch(NotSupportedException consumed){
      ut=null;
      }

      doTheStuff();

      if (ut!=null){
      ut.commit();
      }

      } catch (Exception e) {

      if (ut!=null){
      try {
      ut.rollback();
      } catch(Exception e1){
      log.error(e1);
      e1.printStackTrace();
      }
      }

      log.error(e);
      e.printStackTrace();
      }

      The reason we catch and consume the NotSupportedException is to handle the fact that a transaction may already be active. It's this part that worries me as to whether we are doing something heinous here.

      What do you all think? Would you say "Don't do this, use Session Facades instead!"

        • 1. Re: Correct use of UserTransaction in webapp?
          Darran Lofthouse Master

          My first comment would be "Don't do this, use Session Facades instead!"

          By using a session facade you will get transactions for free.

          It would also allow you to move your we application to a different container not running in the same JVM if you ever needed to.

          Once you have placed all of your logic behind a session facade it would also make it easier to implement other clients, e.g. You may in the future decide you want to expose the logic using web services.