Dominic Cioccarelli wrote: > Given that a stateless session bean can't maintain conversational state, why > bother creating multiple instances (instance pools)?
Because it can have state that is not conversational. > It would seem to be > more efficient just to use a single instance to serve all clients. In a couple of classes of problems, absolutely. >>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. Or instances are created on demand since the new dogma seems to be that object caching is bad (refer to the HotSpot sessions from last J1). It does depend on whether setSessionContext is cheap or not though. > 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. Object instantiation is pretty snappy these days, so that's not such a big issue. > 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). One of the key principles of EJB seems to be "don't trust the programmer", especially when it comes to concurrency management. This is what shaped the spec, and for good and bad, that's the game. > 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)! Put the state in a static variable, which can be shared by all instances. > Conclusion: Is the thread safety provided by a stateless session bean worth > the associated constraints? Since you included the word "worth" in the question the only reasonable answer is "it depends". /Rickard -- Rickard �berg Author of "Mastering RMI" Chief Architect, TheServerSide.com The Middleware Company - We Build Experts! =========================================================================== 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".
