well singletons are hard to implement in EJB but what about using a Stateless Session Bean with max-cache setting to 1 ?(for container that support it). This way the container will create a single instance and serialize access to it....what do you think about it??
I'm kinda confused. I thought that the whole purpose of singleton classes is that they retain their state between accesses, and obviously there is only one of them. This is quite contrary to the purpose of StateLESS session beans, where you should assume that state would be destroyed between accesses. Surely the best way would just be to have as many session beans as you like and access a normal singleton class from them. Threading might be an issue, but this can be dealt with.
Corretc me if I am wrong:
What about keeping a normnal stateless seesion bean as an application level (scope) variable in the JSP.
Doesn't that mean that all instances of particular jsp/servlet will have an access to one specific copy of SLSB? You cannot access the same instance of SLSB from two different places.
Yes, you can do this, but I don't think that invalidates my point. Holding Bean references is common practice. If you hold the bean reference in the JSP, you cannot make any assumptions about its state from one invocation to the next. The SLSB may have been passivated/reactivated between invocations, or as Alex says, another JSP instance may have used the Bean.
Alex, I don't think that's right. You CAN access the same instance from two places, just not at the same time.
Yes, that's exactly what I meant - the same time is a keyword here. But who gives you guarantee that it will not be used at the same time?
Yes I agree , U guys are right.
I guess <b>single thread model</b> is the only way.
But this just proves my original point - a single SSB is NOT the way to implement a singleton function.