Singleton or Stateless Session Bean

Discussions

EJB design: Singleton or Stateless Session Bean

  1. Singleton or Stateless Session Bean (2 messages)

    what would a J2EE expert recommend using in this situation a singleton or Stateless Session bean?

    Multiple transactions are coming through the J2ee system after several DB updates etc. They need to be rebuilt as messages and sent to a legacy as400 system running IBM websphere MQ 5.3
    currently I have created a SLSB that builds a JMS message and places it in a remoteQ defintion. It works fine but.. I have all the initialization code( QCFm Q lookup) in the the ejbCreate() which is fine if the SLSB is always putting to the same remote Queue, but now it needs to be putting to 12 different queues. I am told I should not put the initialization code in the service method of the session bean though, so should I go to a singleton instead? what are the advantages of using a singleton over the SLSB?

    thanks

    Threaded Messages (2)

  2. You can create a abstract helper object and have your sending code in there. Concrete helpers then extend the abstract helper and initialize connections to individual queues. Your session bean will create the corresponding helper when being initialized and invoke the helpers in the service method.

    // I hope this code formatting is preserved

    public class YourSLSessionBean ... {
       private AbstractHelper helper;
       public void setSessionContext(SessionContext ctx) {
          // Get the queue name from the environment and
          // initialize corresponding concrete helper
          helper = new QueueOneHelper();
          helper.createConnection();
       }

       public void service(Message message) ...{
          helper.send(message);
       }

    }

    // Using Template Method pattern from GoF
    public abstract class AbstractHelper {
       public abstract void createConnection();
       public abstract void destroyConnection();
       public abstract Connection getConnection();

       public final void send(Message message) {
       getConnection().send(message);
    }

    public class QueueOneHelper {
       Connection myConn;

       public void createConnection() {
        // Create connection to queue one
         myConn = ...
       }
       public void destroyConnection() {
         myConn.close();
       }
       public Connection getConnection() {
          return myConn;
       }
    }



    And finally, deploy your session bean 12 times, with different names and environment variables helping them figure out which of the helpers they have to initialize.

    I think singleton is an "almost dead" pattern while you are in EJB-J2EE land as it meddles with synchronized keyword. Look at the singleton vote in OOPSLA'04 http://martinfowler.com/bliki/OOPSLA2004.html
  3. synchronization[ Go to top ]

    I think singleton is an "almost dead" pattern while you are in EJB-J2EE land as it meddles with synchronized keyword

    IMO:

    1) you do not need to use the synchronize in this case. Who cares if your initialization will be called ones ot twice.

    2) you should be careful with the "synchronize" in the J2EE, but it is used so many times in the core JDK anyway (e.g. SecurityManager), so you can carefully use it also.