I'm also interested why an EJB container makes a pool for stateless session beans and don't creates only one instance and let multiple threads execute in, it's similar to servlet execution, isn't it? Multiple requests to a servlet can be responded by only one servlet simultaneously with many threads executing the same method.
I don't understand Rickard answer: Because it can have state that is not conversational. What's conversational state? Could you explain more? Thanks ----- Original Message ----- From: "Rickard" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, February 15, 2002 7:31 AM Subject: Re: Why not use just a single Stateless Session Bean? > 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". =========================================================================== 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".
