The Life Cycle of Stateful Session Beans

Because stateful session beans are bound to a specific client and maintain conversational state, WebLogic Server cannot use a free pool mechanism to keep method-ready stateful beans available. Instead, WebLogic Server uses a cache that stores active EJB instances in memory so that they are immediately available to service their client's method calls.

However, stateful session beans consume memory resources. For this reason, special provisions are required to ensure that fixed memory resources allocated to WebLogic Server do not become constrained by an increasing number of clients calling methods on stateful beans. To accommodate a large stateful session bean client base, WebLogic Server's EJB container swaps the unused stateful bean instances out to virtual memory by using Java object serialization. This process, known as passivation , conserves memory resources by limiting the number of stateful bean instances that can be in memory at any given time. When a client calls a remote method on a stateful session bean's remote interface, and the bean instance is discovered to be passivated, the EJB container loads the bean instance back into memory by deserializing the bean instance object. This process is known as activation . Both concepts are critical in understanding a stateful session bean's life cycle.

As shown in Figure 20.9, a stateful session bean can exist in three states.

Figure 20.9. The life cycle of a stateful session bean.

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

Table 20.6. Legal Operations on Stateful Session Bean Methods

Method	Operation
newInstance()	Called by the container and signifies the beginning of the life cycle.
setSessionContext(sc)	Called by the container to pass in environment information.
ejbCreate()	Called by the container to create a bean instance in the method-ready pool.
ejbCreate(args)	Called by the container to create a bean instance in the method-ready pool.
ejbPassivate()	Called by the container before passivation.
ejbActivate()	Called by the container after activation.
ejbRemove()	Called by the container to remove an instance of the session bean.
afterBegin()	Called by the container when invoking a transactional method.
beforCompletion()	Called by the container after a transaction commit has been requested .
afterCompletion(boolean)	Called by the container and gives the status of commit or rollback.

The Does Not Exist State

When WebLogic Server is first booted , no stateful session bean instances exist.

The Method Ready State

As clients look up and obtain references to individual beans by calling Create< Method > on the home stub, WebLogic Server initializes the new stateful bean instances by calling newInstance() , setSessionContext() , and, finally, ejbCreate() on the bean, returning the EJBobject reference to the client. After the bean is created, it is immediately considered to be in a Method Ready state and placed in the cache. Hence, the number of stateful beans that can exist in a Method Ready state is client driven, not controlled by the EJB container. In the Method Ready state, the stateful bean instance serves its client's method calls and remains in this state until one of the following occurs:

• The client calls the ejbRemove() method on the stateful bean, at which point the bean transitions to the Does Not Exist state.

• The container passivates the bean, at which point the bean transitions to the Passivated state. Passivation uses the Not Recently Used (NRU) algorithm by default, which passivates any recently unused stateful beans.

• The stateful bean is timed out of cache by the container, at which point the stateful bean is in the Does Not Exist state. A WebLogic administrator can specify the amount of time a stateful bean exists before it's destroyed .

The Passivated State

Immediately before passivation, the EJB container calls the ejbPassivate() method on the stateful bean, which allows the developer to provide code to deallocate open resources, such as JDBC connections, gracefully. The container passivates the bean only after the ejbPassivate() method has been called.

The resources and information that can be preserved for a stateful bean in a Passivated state include the following:

• JNDI Environmental Naming Context

• References to the session context

• References to other beans' home interfaces

• References to other beans' remote interfaces

• The JTA UserTransaction type

• Primitive data types and serializable objects

Note

The EJB container activates a stateful bean by calling the bean's ejbActive() method. The bean developer can add code in this method to allocate resources that were closed during passivation and to initialize transient attributes to the proper values.

Only the WebLogic EJB container can transition a stateful bean into the Passivated state. Therefore, to maintain continuous high performance, WebLogic Server reserves the cache for active and recently used stateful session beans. When a stateful bean no longer meets this criteria, it becomes eligible for passivation. This does not imply that a bean meeting this criteria will be passivated; the EJB container takes other factors, such as constraints on server resources, into consideration before a stateful bean is passivated. However, you can influence passivation of stateful session beans through the weblogic-ejb-jar.xml deployment descriptor elements described in the following sections.

 <max-bean-in-cache> 

This element specifies the maximum number of stateful beans of a specific class that are allowed in memory. When <max-bean-in-cache> is reached, WebLogic Server begins to passivate some beans that have not been recently used (Least Recently Used [LRU]) by the client. The default value of <max-beans-in-cache> is 100 . If <max-beans-in-cache> is reached and all EJBs in the cache are being used by clients, WebLogic Server throws a CacheFullException .

When analyzing ways to increase performance through the <max-bean-in-cache> element, you should analyze the operation of your stateful bean application and include answers to the following questions:

• How does the stateful bean application relate to the JVM heap size?

• What is the total number of beans being deployed?

• What types of EJBs are being deployed: session, message-driven, or entity beans?

• What is the memory footprint for deployed beans?

• What is the expected client request load?

Based on these statistics, you can reach a suitable value for the <max-beans-in-cache> element. Ideally, the setting you select should not exceed the available JVM heap memory or bring WebLogic Server to a halt by competing for memory.

 <idle-timeout-seconds> 

This element defines the maximum length of time a stateful bean should remain in the cache, after which WebLogic Server can remove the bean instance if the number of beans in the cache approaches the limit of <max-beans-in-cache> .

You can specify explicit passivation of stateful EJBs that have reached <idle-timeout-seconds> by setting the <cache-type> element in the weblogic-ejb-jar.xml file, which specifies the order in which stateful beans are removed from the cache. This setting has two values ”Least Recently Used (LRU) and Not Recently Used (NRU):

• If you specify LRU, the container passivates the bean when <idle-timeout-seconds> is reached.

• If you specify NRU, the container passivates the bean when there is pressure in the cache.

Note

<idle-timeout-seconds> determines how often the container checks to see how full the cache is. The default is 600 .

After a stateful session bean instance is passivated, a client must use the EJB instance before <idle-timeout-seconds> is reached. Otherwise, WebLogic Server removes the passivated instance from disk (Does Not Exist state).