How a Stateful Session Bean Maintains the session??

[suresh guru]

Hi
I would like to have a clear explanation for How & where the Stateful EJB maintains the sesssion for the particular client. ie( in subsequent requests how the bean corectly identifies that the incoming request is for that bean.). I saw in some websites & many of the sites says that the session is maintained through the instance variables present in the bean & some are saying that an object reference will be passes back &forth b/w cilent & EJB
Pls explain me in detail
Suresh

[Lasse Koskela]

How & where the Stateful EJB maintains the sesssion for the particular client.

The how depends on the implementation as does the where (although you can safely answer this one with "on the server-side").
Here's a general description of the process:
1) The client fetches a reference, a proxy, for a stateful bean. The reference he gets contains the vendor-speficic information needed for the EJB Container to recognize the correct bean instance.
2) The EJB Container receives the invocation and finds the bean instance the request is intended for. This can be done at least in a couple of different ways:
2.a) The EJB Container lets the bean instance hold the state in its instance variables and passivates the bean if necessary.
2.b) The EJB Container holds the state somewhere else, in some kind of a database, and picks the bean instance from an anonymous pool (a bit like stateless session beans) giving the state to the bean instance just-in-time before delegating the method call.
[ August 11, 2003: Message edited by: Lasse Koskela ]

[Brian Nice]

I am still a little unclear on this too. Say I have a client who does a JNDI lookup, and creates a stateful session bean and calls a couple of methods. Now I have another request from the same client. I have to do another JNDI lookup and create another stateful session bean. So the container somehow knows that this is the same client and therefore needs to use the same stateful session bean?
Brian

[Pradeep bhatt]

No! When the client creates a stateful session bean it gets the reference to the bean. After the client finsihes calling the 2 methods it can still save the reference or get the Handle. If the client needs to call more methods it uses the same refernce to invoke the methods on the stateful session bean.
If you do another JNDI lookup it will be another bean altogether and methods invokes will be on the new stateful bean thereafter and not on the old one.

[suresh guru]

Hi pradeep
I am still unclear on the concept of getting reference to the SFSB. How the reference could be maintained for a bean (which could be possibly pooled/passivated by the container).

:roll:

[Lasse Koskela]

I am still unclear on the concept of getting reference to the SFSB. How the reference could be maintained for a bean (which could be possibly pooled/passivated by the container).

Consider the following scenario:
1) A client logs in to your web application. The LoginServlet creates a reference to a stateful session bean called LoginSession, populates it with some login-related parameters, and stores its EJBHandle into the HttpSession.
2) The client navigates your web application without needing the LoginSession EJB. The EJB Container decides to passivate the bean instance's state into disk.
3) The client navigates your web application and ends up requesting a page where the resulting HTML displays how much time has elapsed since the user logged in. The DisplayLoginServlet (or a JSP) would read the EJBHandle from the HttpSession, ask the EJBHandle to recreate a reference to the stateful session bean, and invokes the getTimeSinceLogin() method. The EJB container recognizes that the bean instance being referred is not "alive" and activates the state from disk before delegating the method invocation.