In an SLSB, each method is independent of the other methods. There is also an implied understanding that a method should not update the state of the object becasue the next scheduled method is not guranteed to get that updated state. And I haven't seen in the spec that when a method scheduled for an SLSB it's internal state is going to be initialized to the original state (in other words the create method being called). Which means one can have dirty data in SLSB if a mehtod (local or remote) happens to update the state. As a result, it is reasonable to assume that, no method should update the internal of an SLSB. That also means that we will have only read-only private variables. If that is the case, why can't the EJB container simply allow multiple threads call into the same SLSB all the time, saving lots of object creations. There is also this restriction that at any given time, only one thread is allowed in a bean. Does this restriction really make sense here? I am sure you can still apply transactional gurantees with out this restriction. Can someone comment on this? Thanks Satya. =========================================================================== 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".
