Discussions

EJB programming & troubleshooting: Static classes in a EJB framework

  1. Static classes in a EJB framework (7 messages)

    Hello,
    I am trying to use an generic class in a Message Driven Bean framework. The framework houses many other classes / beans which are independent of each other. Assume that the name of the generic class is A and it keeps a running counter. I want to use another class B to call A for incrementing the counter. Class B might have other deveried and/or associated classes C, D, E, which might have to update the counter also by calling the Class A. If I was writing a pure java program static will the thing to do for class A. But since I am running in a EJB framework I can't do that. I am also using a command patter framework and therefore cannot use session beans also.

    The question is is there any way for me to keep the running counter in class A without passing it to classes C, D, and E.

    Thansk
  2. Static classes in a EJB framework[ Go to top ]

    The typical solution to this issue in the EJB work is to bind your counter class (class A in your case) using JNDI when the server starts, and retrieve it in all the classes that need it via a JNDI lookup.

    The JNDI binding operation will be server specific, but the rest of the logic will not be.
  3. A lightweight solution is to use singleton-pattern.
    You may want to put the static class into the system classpath in order to share the static class across EJBs.

    If the counter needs to be shared across multiple JVMs, it's nice to implement the counter as a entity-bean.
  4. I will really like to use the static classes. But since I am using the command framework (the housed classes in the container should not know if they are in J2ee or not), I can't use the EJB aware or the J2ee aware code while writing the classes A, B, C, D etc. The counter should not be shared among different components but simply an instance of the class and its subclasses/assoicated classes. In other words, simply across an instance of a bean.
  5. I will really like to use the static classes. But since I am using the command framework (the housed classes in the container should not know if they are in J2ee or not), I can't use the EJB aware or the J2ee aware code while writing the classes A, B, C, D etc. The counter should not be shared among different components but simply an instance of the class and its subclasses/assoicated classes. In other words, simply across an instance of a bean.
    In that case, I suggest you use a static, encapsulated in some sort of accessor method:

    public class Counter {
        private static final Counter SINGLETON = new Counter();

        public static int nextValue() {
            return SINGlETON.updateCount();
        }

        private int count;

        private synchronized int updateCount() {
            return ++count;
        }
    }

    In your other classes:

    int nextValue = Counter.nextValue();

    Bear in mind that this class will only function correctly within a single JVM; if you have a cluster of EJB servers, you will get multiple counters.

    However, by encapsulating access to your counter, you have the freedom of switching to a more sophisticated, JNDI-registered counter if you need it.
  6. I need to thread the application in a single JVM (I am using websphere). Each thread will need its own counter. The approach you suggested seems not to work because the static member will be shared by all the threads/beans of the application object. Please correct me if I am incorrect....
  7. Static fields could cause a server slowdown or unexpected behavior.

    In fact , EJB specification doesn't allow bean providers to use static values in EJB implementation.
  8. Ah! I misunderstood. I thought you wanted a global counter rather than a thread-specific counter.

    There is no easy way to implement a thread-specific counter in an EJB server. The simplest thing to do is to pass the counter object around using method parameters.

    Outside the EJB server, you could do clever things with ThreadLocal variables, but this is will almost certainly break in an EJB server.