Weblog

Tuesday November 29, 2005

Transactions and JMS I started to talk about JMS thence I might write a few sentences about transactions. Very often use case is that you deliver message and then this message is stored in database. How we can solve this. Should we use JTA for this?
I hope that reader knows that you mustn't use global transaction for consumer and producers. Why? Because, having all producers and all consumers participate in one global transaction would defeat the purpose of using a loosely coupled asynchronous messaging environment. JMS transactions follow the convention os separating the send operations from the receive operations. Which ways do we have for transactions with JMS?

• If you are using only JMS in your transactions, you can create a JMS transacted session. A JMS transacted session supports transactions that are located within the session. A JMS transacted session's transaction will not have any effects outside of the session. For example, rolling back a session will roll back all sends and receives on that session, but will not roll back any database updates. Enable to this way, simple set first parameter to true in createSession method.
• If you are mixing other operations, such as EJB, JDBC, with JMS operations, you should use a Java Transaction API (JTA) user transaction in a non-transacted JMS session. In this case you should first get lookup UserTransaction using JNDI and then start, perform desired operations and commit all like in this snapshot:

        UserTransaction txt = (UserTransaction) ctx.lookup("UserTransaction");
        txt.begin();
        // make JDBC stuff and send message
        txt.commit();
     

• Use message driven beans with CMT. In this case enable container manage transaction in ejb-jar.xml file. Define Container as type of the transaction in this file and use Required for trans-attributes. These values are setup by default for all MDB that are created in NetBeans. Then you can use the MDB context in onMessage method like this:

      public void onMessage(Message aMessage) {
          try{
          if (aMessage instanceof ObjectMessage){
              // process message
              Order order = (Order)((ObjectMessage) aMessage).getObject();
              Connection conn = getDS().getConnection();
              // insert Order in DB
              ...................
          }else{
              logger.log(Level.SEVERE,"Only object messages are supported.");
          }
          }catch(SQLException ex){
             context.setRollbackOnly();
          }
      }
    

  I encountered one issue with this approach in Sun Aplication server. Messages are redelivered again and again. It means that you can flood your server with many messages. BTW, it's good test of Sun App server for DOS attack :-). I know that Jboss allows to setup of number of redelivering but I can't find it for Sun App server. Therefore, I suggest to use a little bit approach, throw EJB exception. What's happened when the database will be offline? Under container-managed transaction demarcation, upon receiving a runtime exception (EJBException extends Runtime exception) from a MDB the container roll-backs the container-started transaction and the message is delivered in dead queue. Below is same sample that throws EJBException.

      public void onMessage(Message aMessage) {
          try{
          if (aMessage instanceof ObjectMessage){
              // process message
              Order order = (Order)((ObjectMessage) aMessage).getObject();
              Connection conn = getDS().getConnection();
              // insert Order in DB
              ...................
          }else{
              logger.log(Level.SEVERE,"Only object messages are supported.");
          }
          }catch(SQLException ex){
             throw new EJBException(ex);
          }
      }