Session Bean Lifecycle
The application server is responsible for many resources. The way in which it hands out and
manages the lifecycle of each Enterprise JavaBean is most important here. For system design
purposes this is important, but I only describe how this works at a very high level because it is
out of the scope of this text.
An important concept to know is instance pooling . For efficiency purposes the application
server will pool instances of each EJB. By maintaining several instances of an individual bean
and sharing them among clients, the application server can reduce the amount of time neces-
sary to create and remove a bean every time a client requests one. The client holds a remote
interface to a bean, but in reality this remote interface interacts with a container class around
the bean instance.
A session bean can be in several states while the application is running. Different actions per-
formed by both the client and the application server can move the bean instance between the
states. I briefly describe the states and movement for each type of session bean in the follow-
ing text. Full descriptions, including state diagrams, are in the EJB Specification.
Stateless Session Beans
A stateless session bean can exist in only two states— does not exist and method-ready
pool . The does not exist state is the state that the bean is in prior to the application server
creating the bean and moving it into the pool.
The method-ready pool state is the state that the bean is in when the bean is on the server
waiting for a client to request it. As you have seen, a stateless session bean holds no state
between method invocations. This means that when the bean is finished processing a request
for a client, it is immediately moved back into a waiting state until another request is made for
its services. Even if the client maintains a copy of the remote interface for the bean, it is only
attached to an actual instance of the bean for the duration of one method call.
Stateful Session Beans
Stateful session beans have a slightly modified lifecycle. We will review the basics at a high
level. A stateful session bean also begins in the does not exist state. From here it will be
moved into the method ready state when a client invokes any creation method.
When it is in the method ready state, it is considered to have client-specific conversational
state, and that instance of the bean belongs to the client. It will continue to service that client's
requests. It can be removed from this state back into the does not exist state when the client
calls the remove method.
Another possibility from the method ready state is to have the bean passivated . Passivation
occurs when a client has a remote interface to a stateful session bean, but is in between method
calls; the application server can choose to allow the bean instance to service another client.