This problem can arise in these situations:
- The lifetime of a SFSB is connected to the lifetime of its client.
Your SFSB works fine, if you have a command line client for example. When the command line application is terminated, the SFSB is removed as well.
If the SFSB is used by a JSP/servlet for example, it's lifetime ends, when the HTTP request is completed. If it is to survive the HTTP request, you have to put it's handle in the HTTP session: After you have got an instance from a JNDI lookup, you should put that instance as an attribute in the HttpSession
. The next HTTP request to use this SFSB must get the handle from the HttpSession
.
- Each JNDI lookup returns a new instance
A quote from EJB 3.1, 4.6 Stateful Session Bean State Diagram
When a stateful session bean is looked up or otherwise obtained through the explicit JNDI lookup mechanisms, the container must provide a new stateful session bean instance, as required by the Java EE specification (Section “Java Naming and Directory Interface (JNDI) Naming Context” [12]).
So you should not lookup the SFSB more than one time.