The Life Cycle of Stateless Session Beans

The WebLogic EJB container completely manages the life cycle of a stateless session bean. As shown in Figure 20.8, a stateless session bean can exist in three states.

Figure 20.8. The life cycle of a stateless session bean.

The legal life cycle operations permitted on stateless session beans' methods are summarized in Table 20.5 and discussed in the following sections.

Table 20.5. Legal Operations for Stateless Session Bean Methods

Method	Operation
newInstance()	Called by the container and signifies the beginning of the life cycle.
setSessionContext()	Called by the container to pass in environment information.
ejbCreate()	Called by the container to create a bean instance in the method-ready pool.
ejbRemove()	Called by the container to remove an instance of the session bean.
xxxMethod()	Called by the client to process a business request.
ejbPassivate()	Must be implemented in the bean class but not called by the container.
ejbActivate()	Must be implemented in the bean class but not called by the container.

The Does Not Exist State

In the Does Not Exist state, a stateless session bean literally does not exist and has not been instantiated . Also, the stateless bean has no identity. For example, by default, no stateless bean instance exists in WebLogic Server during its boot process.

The Method Ready Pool State

If the container decides to instantiate a stateless session bean, it does the following:

1. Calls the newInstance() method on the stateless bean class to create a new instance. The EJB container can perform instance creation at any time because there is no direct relationship between a client's call of the create() method and the creation of a bean instance.

2. Calls the setSessionContext() method on the new bean instance, passing a SessionContext object as the parameter. The session bean uses this object to communicate with the EJB container.

3. Calls the ejbCreate() method on the new bean instance to initialize the bean.

Note

A stateless session bean can implement only the no-argument constructor.

The stateless session bean instance is now in the Method Ready Pool state, ready for any client to delegate a method call. While the bean is in this state, it exists within the EJB container's free pool, which is a repository for stateless beans instantiated by the EJB container. The free pool stores unbound stateless beans that are not active and are processing a method call. WebLogic Server uses the free pool to improve performance and throughput for stateless beans, including message-driven beans.

When WebLogic Server starts, if stateless session beans have been deployed to the server, the WebLogic EJB container automatically instantiates multiple instances of the beans, as specified by the value of the <initial-beans-in-free-pool> element in weblogic-ejb-jar.xml . These bean instances are placed in the free pool, ready to service incoming remote method calls. Populating the free pool in this manner improves the initial response time for activating a stateless bean instance because initial requests for the bean can be satisfied without generating a new bean instance.

Note

<initial-beans-in-free-pool> defaults to 0 if the element is not defined, which implies that WebLogic Server does not prepopulate the free pool with any stateless bean instances.

The EJB container creates new instances of stateless beans as needed for concurrent and parallel method processing. However, the maximum number of stateless session bean instances that can be accommodated in the free pool depends on two factors:

• The value of the <max-beans-in-free-pool> element in weblogic-ejb-jar.xml , which places an upper boundary on the number of stateless bean instances the container creates. An upper boundary might be set when a stateless session bean models a session facade, limiting the number of connections to the back-end server components .

• The number of execution threads available in WebLogic Server to process each remote method call.

Typically, the EJB container no longer needs the bean instance when it needs to reduce the number of stateless bean instances in the method-ready pool. When this happens, the container calls ejbRemove() on the bean, which transitions the bean to the Does Not Exist state. Also, if a RuntimeException occurs within a stateless session bean's life cycle, the bean instance transitions to the Does Not Exist state. This does not affect the client because the EJB container delegates another bean instance from the pool to service the client.

The Busy or Active State

When a client calls a create() method on the home interface, the container does not necessarily create an instance of the bean. It just returns a remote interface. Only when method calls are made against a bean's remote interface does the container find a stateless bean instance in the free pool or create an instance to delegate the method call. The stateless bean then remains active throughout the duration of the client's method call. When that call is completed, the EJB container detaches the bean instance from the client and returns the bean instance to the container's free pool.

A container serializes calls to each session bean instance. For this reason, if incoming method requests surpass the number of stateless beans, the method requests must wait until the EJB container can create additional stateless bean instances or the active beans have been unbound from their clients and placed back in the free pool.