Managing WebLogics EJB Container

Managing WebLogic s EJB Container

WebLogic's EJB container controls the life cycle of an EJB object and provides the runtime environment for deployed EJB components. The EJB container allows a client to obtain the EJB's home object, either through a JNDI lookup, via an EJB reference defined during deployment, or by using the EJB home handle. It provides EJBs with access to a wide range of container-managed services such as the local ENC, transactions, security, persistence, concurrency, locking, caching, clustering, and session-state replication. These services can be configured for a particular EJB component through the deployment descriptors associated with it.

In this section, we examine the life cycle of session beans in WebLogic Server and the impact on the runtime behavior of the EJB container when you adjust the EJB deployment settings. In the next section, we examine the life cycle of entity beans and how you can configure the entity bean pool, caching behavior, and EJB concurrency.

10.3.1 Pool of Stateless Session EJB Instances

WebLogic Server maintains a free pool of stateless session EJB instances, which stores a number of inactive, "method-ready" EJB instances. You can prepare this pool of EJB instances during server startup by specifying an initial-beans-in-free-pool element in the weblogic-ejb-jar.xml descriptor file. When a client invokes a method on a stateless session EJB, WebLogic taps into this pool of method-ready EJB instances. The EJB instance then remains active for the duration of the method call, and is returned to the free pool once the method completes. Because stateless session EJB instances cannot carry any conversational state, they are all effectively identical to each other. Therefore, the actual EJB instance used may vary from one method call to the next because you have no guarantee as to which instance will be returned from the pool.

If a client requests a stateless session EJB, and the pool has not yet reached its maximum capacity, WebLogic simply returns an available instance from the pool. If all EJB instances in the pool are currently active, WebLogic adds a new instance to the pool before returning it. The capacity of the free pool is determined by the maximum available system memory, or by the value for the max-beans-in-free-pool element in the weblogic-ejb-jar.xml descriptor file (if it is specified):

RegistrationEJB 10 4 org.foo.bar.RegistrationHome

If all EJB instances in the pool are currently active and the pool has reached maximum capacity, the next client request for the EJB is blocked until one of the active EJB instances completes its method call and is returned to the pool, or until the transaction times out, in which case a RemoteException (EJBException, for local clients) is thrown.

In general, you should set a maximum limit on the size of the free pool only if you have very specific requirements for limiting its growth. By specifying no upper limit, you ensure WebLogic has more control over the resources and you do not unnecessarily restrict possible opportunities for greater concurrency.

10.3.2 Cache of Stateful Session Bean Instances

Unlike stateless session beans, stateful session beans need to maintain a one-to-one association with a client, and therefore WebLogic is unable to provide a pool of identical instances. Instead, WebLogic maintains a cache of stateful session EJB instances, which holds active EJB instances, including those EJBs that currently are in use and those that were used recently. The stateful bean cache is empty at server startup. The EJB instances get created and cached as clients obtain references to stateful EJB instances. The max-beans-in-cache element in the weblogic-ejb-jar.xml file lets you configure the size of the EJB cache.

Under certain circumstances, EJB instances in the cache become eligible for passivation. In other words, the EJB instance can be removed from the in-memory cache and persisted to disk while preserving its state, thereby freeing up valuable resources. The persistent-store-dir element in the weblogic-ejb-jar.xml descriptor file lets you choose a folder in the server's filesystem that will store all the passivated stateful session EJB instances.

By default, the EJB container regularly examines the cache. If the cache has reached its capacity and the EJBs in the cache are not being used, WebLogic passivates the unused EJB instances. If the cache has reached maximum capacity, but all the EJBs in the cache are currently in use, WebLogic throws a CacheFullException. In fact, you should use the cache-type element in the weblogic-ejb-jar.xml descriptor file to configure how WebLogic ought to passivate stateful session EJBs:

ShoppingCartEJB 15 300 LRU temp org.foo.bar.ShoppingCartHome

The cache-type setting accepts two possible values:

LRU (Least-Recently Used)

The EJB container will passivate the stateful EJB instances after they have been idle for more than idle-timeout-seconds.

NRU (Not-Recently Used)

The EJB container will passivate stateful EJB instances only when there is pressure on WebLogic. In this case, the idle-timeout-seconds setting determines how often WebLogic checks to see if the cache is near its maximum capacity.

By default, WebLogic adopts the NRU caching strategy for stateful session EJBs, which is less eager than the LRU scheme. The EJB container invokes the ejbPassivate( ) method on the EJB instance before it is actually passivated. You can use this method to ensure that the EJBs state can be serialized safely to disk. This means that any fields that need not be passivated should be declared as transient, and all nontransient fields should represent serializable objects.

The max-beans-in-cache and idle-timeout-seconds settings also influence how WebLogic removes stateful session EJBs from either the cache or the disk. If a client doesn't use a passivated stateful session EJB before the idle-timeout-seconds duration, WebLogic removes the passivated EJB instance from disk. When the cache is close to its maximum capacity, WebLogic removes EJB instances that have not been used for idle-timeout-seconds, instead of passivating them to disk. This ensures that inactive EJBs do not burden the cache or disk resources.

Moreover, you can prevent WebLogic from removing idle EJBs altogether by setting the idle-timeout-seconds to 0. However, the EJBs still may be passivated if cache resources become scarce.