Exactly how is the state retained from client to application server? In other words: when the client makes its second call to the stateful session bean, how does that bean know it is coming from that same specific client?
When a client creates a stateful session bean, the client will be associated to that session bean in the container for the life of the client. The application server always knows the client identity because the EJBObject that is associated to the bean class is maintained and kept "alive" by the container, even if the bean itself is passivated, written to a second storage, and destroyed. If, for example, the bean was passivated and the client invokes a method on the session bean, the container will associate the identity of the client by virture of the EJBObject that is being invoked. The container will then recreate a stateful session bean instance from the state that was written to a secondary storage, and service the method call.
Conceptually speaking, the client is always calling the same stateful bean, but physically speaking, the container may be using a completely differnt bean instance in memory.
The client is required to maintain the remote reference to the EJBObject while invoking methods on the bean. For a stand-alone application, this is easy to maintain. For web applications, you may need to store the EJBObject reference in the HTTP session. If the client loses the EJBObject reference, I don't believe the client can obtain access to the same stateful bean. I may be wrong on that statement, but since stateful beans don't have finder methods, you must always use a create() method to gain access to this type of session bean, so once you lose the EJBObject reference from the client side, the stateful bean might also be lost to that client.
I'd like to hear other people comment on this as well.