I am not able to figure out the exact difference between stateful session bean timeouts and passivation. What I presume is, Passivation is done at the EJB Container's discretion. It is done as and when the container feels to free the system resources, it evicts the least recently used bean instance from the memory and does not store them in any instance pool, as pooling is not supported in stateful session beans. What exactly happens in Session Time outs?
Could somebody help me in understanding this concept?
I disagree that stateful session beans are not pooled. Data related to staeful session beans is serailized.
Time out in container context, I am not sure but might be related to Session time out (Client has not responded for a long time and webserver takes the decision to kill the session of the client. In that case all data related to the client will be destroyed.)
Hi Karthik ,
For cached EJB instances: When resources become scarce and there is a need for memory in the cache, WebLogic Server examines EJB classes that are approaching their max-beans-in-cache limit. Of those beans, WebLogic Server takes EJB instances that have not been used for idle-timeout-seconds and removes them from the cache (rather than passivating them to disk). Removing, rather than passivating, the instance ensures that "inactive" EJBs do not consume cache or disk resources in WebLogic Server.
If a stateful bean has been idle for longer than idle-timeout-seconds, WebLogic Server may remove the instance from memory as a result of regular cache maintenance, even if EJB's max-beans-in-cache limit has not been reached.
For passivated EJB instances: After a stateful session EJB instance has been passivated, a client must use the EJB instance before idle-timeout-seconds is reached. Otherwise, WebLogic Server removes the passivated instance from disk.
Timeouts and passivation are very different and not really inter-related. The basic difference is this.
Passivation is the act of a container serializing an in-memory stateful bean to persistant store to save memory. The beans have yet to reach their timeout. A client could request a method on the instance and the container will recover from persistant store.
TImeouts are used to DESTROY a stateful bean after n seconds of inactivity. The idea is that after n seconds it can be assumed the client is simply gone forever. This is to protect against a client crashing and 'leaking' a stateful session bean
Internet Applications Division
Thanks for all your explanations. That was really helpful in understanding the exact difference between timeouts and passivation. Thanks again.
If we want to keep state of user session for a relative
long time, what will be your suggestion ? In Servlet session
or in a stateful session bean ? ( statefule session has timeout problem ).
One important reason to keep state in a stateful session bean is to make business work flow independent of presentation layer. If we use stateful bean , timeout is a problem. If we use servlet session to keep state, then other
client will have to implement their own session mechanism .
Any thoughts ?
Can you please define what you mean by inactivity of a SFSB? In my environment, I have noticed that even if the timeout expired, the SFSB instance is still kept in the cache in NRU mode.
What happens if the max bean count has not reached and the timeout expires for a SFSB instance in the cache? Is it kept until the max bean count is reached or, is it removed and destroyed ?