If you have a need to do what you have described, then use a remote RMI object. You could even use a singleton and wrap your stateless session bean around it (you would just have multiple instances of the same singleton between applications/servers/jvms and whenever a new classloader is used). Just be-careful and properly maintain the state between multiple transaction calls, in case a transaction needs to rollback the changes you have just made to your global data.
-AP_ http://www.alexparansky.com -----Original Message----- From: A mailing list for Enterprise JavaBeans development [mailto:[EMAIL PROTECTED]]On Behalf Of Dominic Cioccarelli Sent: Thursday, February 14, 2002 6:38 PM To: [EMAIL PROTECTED] Subject: Why not use just a single Stateless Session Bean? O.k, I know that this subject has come up a few times, but I'm not satisfied with any of the answers, so I'll ask it again ;-). Given that a stateless session bean can't maintain conversational state, why bother creating multiple instances (instance pools)? It would seem to be more efficient just to use a single instance to serve all clients. >From what I can see the reason seems to be that with EJBs (unlike RMI) multiple clients can't invoke methods on a single EJB at the same time. Requests are serialized. Therefore instance pools are used to increase performance. Personally I feel that not allowing concurrent access to _stateless_ session beans is an unnecessary constraint. Sure it means that bean developers don't need to deal with concurrency issues, but it also decreases performance leading to the use of instance pools and the associated object instantiation overhead. If I were to use a single RMI server object, on the other hand, 1000 clients could theoretically invoke methods on it simultaneously. Concurrency would only be a problem if I had methods accessing variables at the object scope (but good programmers should be conscious of these issues). The reason I ask is that I have an object which needs to be implemented as a stateless session bean. The problem is that when it is instantiated it needs to load (and cache) a lot of data. Our current implementation uses a singleton which is very efficient as this (the information is loaded only once for all clients). Switching to a stateless session bean would mean that this information would need to be loaded for each instance. Furthermore, performance wouldn't be as good, i.e. if I had 10 clients and 5 beans, then 5 of the clients would be left waiting. In comparison, an RMI server object could serve all 10 clients simultaneously (using a single object)! Conclusion: Is the thread safety provided by a stateless session bean worth the associated constraints? =========================================================================== 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". =========================================================================== 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".
