Dominic Cioccarelli wrote: > To counter the performance impact imposed due to lack of > threads EJB server vendors must resort to complicated techniques such as > instance pooling which isn't implemented in the same way in every EJB > server.
Not sure what you're saying here. Are you implying that this restrictions was added because of "lack of threads"? An EJB server is (potentially, and usually) multi-threaded, so that doesn't make sense. > Thread safety in something equivalent to the functionality of a stateless > session bean is hardly complicated: you just have to be careful when methods > are reading or writing variables which are not method scope. Hardly a drama. Well, that's a value judgment that the spec has decided the other way: that ensured correctness with regard to concurrency management is more important than whatever performance can be gained by using singleton instances. /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".
