The biggest difference between the stateful session bean and the other bean types is that stateful session beans do not use instance pooling. Stateful session beans are dedicated to one client for their entire lives, so swapping or pooling of instances isn’t possible.[34] When they are idle, stateful session bean instances are simply evicted from memory. The EJB object remains connected to the client, but the bean instance is dereferenced and garbage collected during inactive periods. This means that each stateful bean must be passivated before it is evicted in order to preserve the conversational state of the instance, and it must be activated to restore its state when the EJB object becomes active again.
The bean’s perception of its life cycle depends on
whether it implements a special interface called
javax.ejb.SessionSynchronization. This interface
defines an additional set of callback methods that notify the bean of
its participation in transactions. A bean that implements
SessionSynchronization can cache database data
across several method calls before making an update. We have not
discussed transactions in detail yet; we will consider this part of
the bean’s life cycle in Chapter 15. This section describes the life cycle of
stateful session beans that do not implement the
SessionSynchronization interface.
The life cycle of a stateful session bean has three states: Does Not Exist, Method-Ready, and Passivated. This sounds a lot like a stateless session bean, but the Method-Ready state is significantly different from the Method-Ready Pool of stateless beans. Figure 11-2 shows the state diagram for stateful session beans.
A stateful bean instance in the Does Not Exist state has not been instantiated yet. It doesn’t exist in the system’s memory.
The Method-Ready state is the state in which the bean instance can service requests from its clients. This section explores the instance’s transition into and out of the Method-Ready state.
When a client invokes the create( ) method on an EJB home of a stateful session bean, the
bean’s life cycle begins. When the create( ) method is received by the container, the container
invokes newInstance( ) on the bean class, creating
a new instance of the bean. Next, the container invokes
setSessionContext( ) on the instance, handing it
its reference to the SessionContext, which it must
maintain for life. At this point, the bean instance is assigned to
its EJB object. Finally, the container invokes the
ejbCreate( ) method on the instance that matches
the create( ) method invoked by the client. Once
ejbCreate( ) has completed, the container returns
the EJB object’s reference to the client. Note that
there can be different, overloaded versions of ejbCreate( ), unlike stateless session beans. The instance is now in
the Method-Ready state and is ready to service business methods
invoked by the client on the bean’s remote
reference.
While in the Method-Ready state, the bean instance is free to receive method invocations from the client, which may involve controlling the taskflow of other beans or accessing the database directly. During this time, the bean can maintain conversational state and open resources in its instance variables.
Bean instances leave the Method-Ready state to enter either the
Passivated state or the Does Not Exist state. Depending on how the
client uses the stateful bean, the EJB container’s
load, and the passivation algorithm used by the vendor, a bean
instance may be passivated (and activated) several times in its life
or not at all. If the bean is removed, it enters the Does Not Exist
state. A client application can remove a bean by invoking one of the
remove( ) methods on the client API, or the
container can choose to remove the bean.
The container can also
move the bean instance from the
Method-Ready state to the Does Not Exist state if the bean times out.
Timeouts are declared at deployment time in a vendor-specific manner.
When a timeout occurs in the Method-Ready state, the container may,
but is not required to, call the ejbRemove( )
method. A stateful bean cannot timeout while a transaction is in
progress.
During the lifetime of a stateful session bean, there may be periods of inactivity when the bean instance is not servicing methods from the client. To conserve resources, the container can passivate the bean instance by preserving its conversational state and evicting the bean instance from memory. A bean’s conversational state may consist of primitive values, objects that are serializable, and the following special types:
javax.ejb.SessionContext
|
javax.ejb.EJBHome (remote home interface types) |
javax.ejb.EJBObject (remote interface types) |
javax.jta.UserTransaction (bean transaction interface) |
javax.naming.Context (only when it references the JNDI ENC) |
javax.ejb.EJBLocalHome (local home interface types) |
javax.ejb.EJBLocalObject (local interface types) |
References to managed resource factories (e.g., javax.sql.DataSource) |
The types in this list (and their subtypes) are handled specially by the passivation mechanism. They do not need to be serializable; they will be maintained through passivation and restored automatically when the bean instance is activated.
When a bean is about to be passivated, its ejbPassivate( ) method is invoked, alerting the bean instance that it is
about to enter the Passivated state. At this time, the bean instance
should close any open resources and set all nontransient,
nonserializable fields to null. This prevents
problems from occurring when the bean is serialized.
Transient
fields are simply ignored.
How does the container store the bean’s conversational state? It’s largely up to the container. Containers can use standard Java serialization to preserve the bean instance, or some other mechanism that achieves the same result. Some vendors, for example, simply read the values of the fields and store them in a cache. The container is required to preserve remote references to other beans with the conversational state. When the bean is activated, the container must restore any bean references automatically. The container must also restore any references to the special types listed earlier.
When the client makes a request on an EJB
object whose bean is passivated, the container activates the
instance. This involves deserializing the bean instance and
reconstructing the SessionContext reference, bean
references, and managed resource factories held by the instance
before it was passivated. When a bean’s
conversational state has been successfully restored, the
ejbActivate( ) method
is invoked. The bean instance should open any resources that cannot
be passivated and initialize the values of any transient fields
within the ejbActivate( ) method. Once
ejbActivate( ) is complete, the bean is back in
the Method-Ready state and available to service client requests
delegated by the EJB object.
The activation of a bean instance follows the rules of Java
serialization,
regardless of how the bean’s state was actually
stored. The exception to this is transient fields. In Java
serialization, transient fields are set to their default values when
an object is deserialized; primitive numbers become zero, Boolean
fields false, and object references
null. In EJB, transient fields can contain
arbitrary values when the bean is activated. The values held by
transient fields following activation are unpredictable across vendor
implementations, so do not depend on them to be initialized. Instead,
use ejbActivate( ) to reset their values.
The container can also move the bean instance from the Passivated
state to the Does Not Exist state if the bean times out. When a
timeout occurs in the
Passivated state, the ejbRemove( ) method is not invoked.
Whenever a system exception is thrown by a bean
method, the container invalidates the EJB object and destroys the
bean instance. The bean instance moves directly to the Does Not Exist
state and the ejbRemove( ) method is
not invoked.
A system exception is any unchecked exception, including
EJBException. Checked exceptions thrown from
subsystems are usually wrapped in an EJBException
and rethrown as system exceptions. A checked exception thrown by a
subsystem does not need to be handled this way if the bean can safely
recover from the exception. In most cases, however, the subsystem
exception should be rethrown as an EJBException.
[34] Some vendors use pooling with stateful session beans, but that is a proprietary implementation and should not affect the specified life cycle of the stateful session bean.