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
The Does Not Exist StateWhen WebLogic Server is first booted , no stateful session bean instances exist. The Method Ready StateAs 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 Passivated StateImmediately 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:
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:
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):
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). |