EJB design: True singleton in EJB

  1. True singleton in EJB (10 messages)

    I have a question I'm sure has been answered already, but searching the archives and patterns I haven't been able to find a solution:
    How do I design a _true_ singleton in EJB?
    By true singleton I mean a class that will act as a singleton even on a clustered system. The regular singleton DP doesn't work when an application is clustered on several machines.
    The only solution we could think of so far is to make the Singleton class a session bean, and define at deployment that there will only be one instance of it. Is there a better way to do this?



    Threaded Messages (10)

  2. True singleton in EJB[ Go to top ]


  3. True singleton in EJB[ Go to top ]

    Home interfaces are singletons (arn't they?)

  4. True singleton in EJB[ Go to top ]

      That’s a right solution (I guess??), because we have also implemented Singleton in the same way.
      Storing singleton object with JNDI tree will also work, but the problem is when the original server fails, this entry (single object) will be removed from the cluster .

  5. How about a singleton and calling the methods from session beans?
    Would that work?
  6. True singleton in EJB[ Go to top ]


    What exactly do you mean by using JNDI? Using JNDI, each user of the singleton will have to load it to it's own box, which actually creates a new instance. I thought the question was about creating one actual *instance* that all requests run through. Otherwise an entity bean would also work (and would atleast be transactional).


    Home objects are abstractions. They are "singleton" (per deployment) in abstract terms, but actually the requests to home objects are delegated to multiple instances of the bean. So in the same sense as my comment above, I don't see how you can actually use them as "singletons".

    The only way I know to create a real singleton is to use either an RMI server object, or a JMS application to pick messages off a queue. I would love to hear other suggetions. In all the discussion I have participated until now (and there have been quite a few here on TheServerSide) I haven't heard of any other portable solution.

  7. True singleton in EJB[ Go to top ]


    Maybe the question is what exactly do we mean by singleton.

    I think the home method will _act_ like a singleton, even if it isn't one. I'll try to explain that one:

    If you have set a variable in a home class, then that variable will always be set when you get that home, cluster or no cluster. That seems consistent with the behaviour I'd expect from a singleton.

  8. True singleton in EJB[ Go to top ]

    Let me perhaps sharpen the point a bit; I indeed need a singleton that has a single instance in the entire application, so behavior "as if" there's a singleton won't be good enough.
    The solution we were thinking about is to hold a single stateless session bean, and tell the container via the vendor specific descriptors to have exactly one instance of the bean, and never to destroy it. This is problematic, because it's vendor dependant. I was thinking of another solution, but I'm not sure how (or even if) it can be implemented: Have a single stateful session bean, and make sure it has only one remote, i.e. somehow I have to pass the single remote instance I have to anyone who needs the bean. I'm not sure if this can be done or if its desireable assuming it can.
  9. True singleton in EJB[ Go to top ]


    I'm not sure I follow your terminology. The home is not a class: it is an interface. No variable can be set on the home, only methods. The home is implemented by the App server, not the user, which means you can't really control what's in the home. You can only affect the home indirectly by defining methods in your bean that the App server will delegate calls to: but that doesn't help you, because multiple bean instances can be assigned to handle delegations to the home. Further, the home object is not really a singleton in the sense that *one* instance of it will be created application-wide. The EJB spec doesn't specify how many instances will be created.


    I may be missing your definition of "business tier". For me, an RMI server object or a JMS consumer can be a part of the business tier. EJBs may be usefull for implementing the business tier, but they are certainly not the only possible implementation of a business layer. "business tier" != "EJB", IMHO.
    If you ment that there is no portable way to implement a true singleton within EJB, I tend to agree.


    Your first approach may work, but it is definately not portable. It also restricts the functionality of your singleton with respect to threading: no two threads can access the singleton at the same time. In a large-scale system, application-wide singletons can be very serious bottlenecks. Having only one thread at a time access the singleton can magnify the bottleneck by an order of magnitude.
    A slightly more scalable approach can be taken at the cost of more portability issues. You can have multiple stateless session beans delegate all their requests to one singleton (implemented normally, using a static field). Deploy this SLSB on one box, and you will get the effect of a multithreaded singleton. However, this is not portable. On some application servers the class-loading strategy may lead to multiple instances of the singleton being allocated.
    The only portable options I know are the ones I listed in my earlier post. The two issues I have with those options are:
    1. They require developing outside the EJB environment, which means they have to be maintained by developers that know what they're doing.
    2. They make your deployment process more complicated, and there is no way that I know of to include these components in the EAR file.

  10. True singleton in EJB[ Go to top ]


    Actually, I mean that RMI and JMS apps will not be running under AppServer's JRE, so they will not be under its control.

  11. True singleton in EJB[ Go to top ]


    That's right. JNDI object is not a true singleton, but at least it acts like one. RMI server and JMS applications exist beyond business logic tier of an application server. However, currently I can't see any solutions that will allow us to create truly singleton in business layer that will work through clustering (and I do not think there is any exists).