I read that the stateful session bean in "method ready" will go to "does not exist" state by ejbRemove() or time out. I have a question here. The waiting-time of time-out should be longer than passivation, right? Then, when it comes to the time-out, why doesn't it go into "passivated state" first?
Hi, It is not necessary for a stateful session bean to go to passivated state always. The container may never call ejbPassivate if it feels that the existing session beans in the pool are sufficient to handle the client requests.The container may call ejbPassivate if a request comes and it sees that all other beans are busy serving clients, and this bean is sitting idle for some time.In this case Container may think like lets passivate this bean and serve the current request using this bean.
I think you raised a good question. Well, here is your answer, it tells you why the bean is simply removed when it times out, and not just passivated. Also, that is explained in HFE.
When the stateful session bean times out (due to user inactivity), the bean still stays alive in the stateful cache on the server. The price for this abandoned bean is: 1. Server memory is not used efficiently - the abandoned bean stays in memory until it is passivated. As the client that created the bean no longer exists, the bean occupies memory unnecessarily. If your stateful EJB is clustered, not calling remove keeps the bean in the cache of the primary server and its replicated counterpart on the secondary server. In addition to the beans, the replication machinery on both the servers also occupies memory. 2. Performance drops - the abandoned bean will be removed from the memory by passivating it to the disk. This affects performance as passivation is an expensive operation that involves serializing the bean to the disk.