EJB programming & troubleshooting: Is there such thing as a Singleton EJB

  1. Is there such thing as a Singleton EJB (3 messages)

    I understand that clients can share access to an instance of EJB using the same instance of the EJB home. However is there any other way to share the EJB instance across different clients. This leads me to my original question, is there such thing are a singleton EJB?

    Here is my sitiuation ....
    I have no control of my clients and the clients can be distributed across JVM's. However I would like to manage the invocations to my bean such that they are dispatched to the same instance of EJB. In addition, I would like to do this without having to persist the bean. Am I out of luck.

    Thanks in advance,
  2. AFAIK, there is only one way to get an in-memory singleton (i.e., without any persistence store): the singleton needs to be outside the EJB container but within the same JVM. Most app servers have some (proprietary) way to achieve this - such as startup classes in weblogic.

    The standard ways to make the same data available to multiple clients all require that the singleton state is stored somewhere - in an RDBMS, LDAP, etc., typically using JDBC or JNDI.

    On top of this storage, you have many ways to load the data and cache it in the app servers memory.

    You can use a normal singleton. But keep in mind that the app server's classloader hierarchy determines exactly what is the scope of a singleton (i.e., which ejbs will 'see' the same instance of the so-called singleton). In general, I don't think there is any app server in which all instances of the same ejb don't use the same classloader.

    Or you can model the data as an entity bean and let the app server handle the caching.

    Or you can use app-server proprietary means to configure a single instance of a stateless session bean. For example,. set max-beans-in-free-pool to 1 in weblogic-ejb-jar.xml. This does not guarantee, though, that the same instance will survive for the lifetime of the server.

    - Ravi
  3. Thanks for the info Ravi. Here is a follow up question.

    Are there any benchmark numbers that demonstrate the cost of using entity beans vs session beans. For example if bean A is a simple session bean and B is a entiry bean, how much slower is B compared to A?

    class A {
     addBalance(int deposit){
       return m_balance=+deposit ;

    class B {
     int addBalance(int deposit) {
       return m_balance=+deposit ;

    I understand this is a very broad question which is probably very difficult to simplify or typify. On top of that, the app server probably does a lot of lazy reads and writes to improve the performance even further. However, is there a general rule of thumb on the performance difference between using entity beans and just plain old session beans. Are we talking about 2x, 5x, 10x, 50x or higher.

  4. The answer of course, is, it depends. On what you are caching, how it's going to be accessed, and how it's going to be loaded (from DB or wherever).

    First, the comparison is not between SessionBean and EntityBean, but between caching data in a SessionBean, versus making the data EntityBeans and letting the container cache them.

    If you cache data in a SessionBean, you are responsible for managing the cache: expiry, making sure that cache doesn't grow and grow and bust the heap, re-loading the cache when the SB is re-instantiated, etc. From that point of view, EBs look good.

    On the other hand, if you need to return a huge number of items from the cache, you might want to bypass EBs and construct value objects directly from the SB. If you can map all your retrieval methods into CMP queries, then it's not too bad. But if not, or if you are using BMP for some reason, then bulk retrieval will kill you.