posted 21 years ago
hi,
what i think is
to limit the number of stateful beans instances in memory, the container can swap out stateful bean , saving its conversational state to a hard disk or other storage ("Passivation").. After passivation a stateful bean, the conversation state is safely stored away, along with the resources being used... when the original clients invokes a method, the passivated conversational state is swapped in to a bean("Activation").. this bean now resumes the conversation with the original client...
It shud be noted that the bean receives the activated state may not be the original bean instance..
Thus EJB does indeed support the effect of pooling stateful beans. only a few instance can be in memory, when there are many clients
As the session context(EJB Context) remains associated with the instance for the lifetime of the instance.. and if the instances are swapping to serve clients while(Passivation/Activation)... their context do come into the picture
correct me if i am wrong
Naveen