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".
