Dominic Cioccarelli wrote: >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. > >[snip] > You're forgetting that stateless session beans can maintain state, just not client state. Stateless beans may be used to provide access to resources whose API is not re-enterent. Synchronization could easily cause deadlocks. Not to mention the problems it would cause for server performance. Thread and transaction coherent pooling is non trivial.
In addition, using the same stateless bean will not make it any easier to create singletons in a clustered environment. --Victor =========================================================================== 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".
