Discussions

EJB design: Activation

  1. Activation (3 messages)

    Actually we know that in case of statefull session bean contatiner passivate the bean's conversational state by using Least Recently Used algorithm if client is ideal or disconnected from the network.And when same client's request has come again then container reads the passivated state back into the memory and assign to any bean intance(it may not be the original bean instance) available in pool.

    Now my question is when same client's request has come again then how container decide that which passivated conversational state has to be activated ?

    regards
    Sabyasachi

    Threaded Messages (3)

  2. Activation[ Go to top ]

    It depends on the server, but in practice it is probably when through some kind of session id (resembling the servlet jsessionid), retained and transmitted by the client and associated on the server with a particular Stateful Session Bean.
  3. Activation[ Go to top ]

    It depends on the server, but in practice it is probably when through some kind of session id (resembling the servlet jsessionid), retained and transmitted by the client and associated on the server with a particular Stateful Session Bean.
    Hi Paul I am not sure about what u said....but I think whwnever the container passivates and instance it keeps a refernce of the EJBObject it belongs to.While Activating it associated the stored values with new instances (using some algorith) and fires a getEJBOBject() to get back a handle which it matches with the eisting Client EJBOBject.

    Thanks Sabyasachi
  4. Activation[ Go to top ]

    For a SESSION stateful bean, the state is maintained as long as the reference to the bean is maintained (or remove called by user of container due to timeout).
    More directly the session lasts from:begin=your bean.create(args) till end=your bean.remove().In between these two calls, many "clients" can ask services from the SAME work session.

    When the stateful session bean is going to passivate, which the ejbobject does it automatically.. the state of the client will be stored into a serializable file along with the session id(which is unique across the clients). so when the same client comes after the threshold time, ejbobject will create a new bean instance and based on the session id it will read the state from the serializable file and restore the state of the client. So the session id is the key which helps the ejbobject to restore the client state from serializable file.