Rickard �berg wrote: > Similar, yes, except stateless session beans ensure that there is > thread-safe access to instances in order to be 100% concurrency safe, > with regard to non-conversational state.
> Note that this is what you get with the SingleThreadModel interface in > servlets. O.k. now I understand. Talk about going back to the future. The creators of the EJB spec (in their immense wisdom) disallow concurrency so that we programmers don't make mistakes (i.e. they _remove_ functionality). One of the great aspects of the Java programming language is its native support for threads. 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. 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. Dom. ==========================================================================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".
