Hello everyone I'm wondering why I'd want to use a Stateless Session EJB if I do not need to call it remotely, and also do not need TX support.
Seems like many people use SSBs that are called by other SSBs in the same JVM, and where they do not necessarily need TXal method calls. I asked someone this question once, and the reply was, "You get automatic instance pooling, so you get higher performance." I thought about this and wondered whether just using a plain old Java singleton would work better. This is assuming that the method calls do not access state in the object. Although this should be true for an SSB, it is not always true, as only one method acts on an SSB instance at once. So a method can put stuff in member variables, and take stuff out, just for convenience. The only thing to watch out for is to not depend on the values of the member variables between method calls. So assuming we don't need that "convenience", the method calls are stateless, and therefore don't need to be synchronized (in the case of a Singleton) or anything. So the situation boils down to: 1) A pool of SSBs that can serve these stateless requests or 2) A single instance of an object (the Singleton) that serves these stateless requests or even 3) A class with static methods that serve all these requests Does one perform better than the other? Obviously 1) has more objects in memory, so that's bad. But does it serve the requests faster? With no synchronization of the Singleton? If 2) (or 3)) is better, I know a lot of people who should be changing their code. Thanks for the feedback, folks. George =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
