Chapter 8 Creating J2EE Applications for BEA WebLogic

Stateful Session EJB Life Cycle

WebLogic Server uses a cache of bean instances to improve the performance of stateful EJBs. The cache stores active EJB instances in memory so that they are immediately available for client requests. Active EJBs consist of instances that are currently in use by a client, as well as instances that were recently in use, as described in the following sections. The cache is unlike the free pool insofar as stateful session beans in the cache are bound to a particular client, while the stateless session beans in the free pool have no client association.

The following figure illustrates the WebLogic Server cache, and the processes by which stateful EJBs enter and leave the cache. Dotted lines indicate the state of the EJB from the perspective of WebLogic Server.

Initializing and Using EJB Instances

No stateful EJB instances exist in WebLogic Server at startup time. As clients look up and obtain references to individual beans, WebLogic Server initializes new instances of the EJB class and stores them in the cache.

Passivating Stateful EJBs

To achieve high performance, WebLogic Server reserves the cache for EJBs that clients are currently using and EJBs that were recently in use. When EJBs no longer meet these criteria, they become eligible for passivation . Passivation is the process WebLogic Server uses to remove an EJB from cache while preserving the EJB's state on disk. While passivated, EJBs use minimal WebLogic Server resources, but they are not immediately available for client requests (as they are while in the cache).

Note that stateful session EJBs must abide by certain rules to ensure that bean fields can be serialized to persistent storage.

WebLogic Server provides the max-beans-in-cache deployment element, which provides some control over when EJBs are passivated.

If max-beans-in-cache is reached and there are EJBs in cache that are not being used, WebLogic Server passivates some of those beans. This occurs even if the unused beans have not reached their idle-timeout-seconds limit. If max-beans-in-cache is reached and clients are using all EJBs in the cache, WebLogic Server throws a CacheFullException.

Note that when an EJB becomes eligible for passivation, it does not mean that WebLogic Server passivates the bean immediately. In fact, the bean may not be passivated at all. Passivation occurs only when the EJB is eligible for passivation and there is pressure on server resources, or when WebLogic Server performs regular cache maintenance.

Removing Stateful Session EJB Instances

The max-beans-in-cache and idle-timeout-seconds deployment elements also provide some control over when stateful session EJBs are removed from the cache or from disk.

• For cached EJB instances: When resources become scarce and there is a need for memory in the cache, WebLogic Server examines EJB classes that are approaching their max-beans-in-cache limit. Of those beans, WebLogic Server takes EJB instances that have not been used for idle-timeout-seconds and removes them from the cache (rather than passivating them to disk). Removing, rather than passivating, the instance ensures that "inactive" EJBs do not consume cache or disk resources in WebLogic Server.
  
  If a stateful bean has been idle for longer than idle-timeout-seconds, WebLogic Server may remove the instance from memory as a result of regular cache maintenance, even if EJB's max-beans-in-cache limit has not been reached.
  
  Note that setting idle-timeout-seconds to 0 stops WebLogic Server from removing EJBs as part of regular cache maintenance. However, EJBs may still be passivated if cache resources become scarce.
• For passivated EJB instances: After a stateful session EJB instance has been passivated, a client must use the EJB instance before idle-timeout-seconds is reached. Otherwise, WebLogic Server removes the passivated instance from disk.

Stateful Session EJB Requirements

The EJB developer must ensure that a call to the ejbPassivate() method leaves a stateful session bean in a condition where WebLogic Server can serialize its data and passivate the bean's instance. During passivation, WebLogic Server attempts to serialize any fields that are not declared transient. This means that you must ensure that all non-transient fields represent serializable objects, such as the bean's remote or home interface. With the EJB 1.1 specification, an EJB's non-transient fields can also include:

• A reference to the EJB's JNDI environment context
• A reference to the UserTransaction object

As of the EJB 1.1 specification, references to the javax.ejb.SessionContext object cannot be declared transient.

Copyright (C) 2005. Sybase Inc. All rights reserved.