Tuning the Stateless Session Bean Pool Tuning the MDB Pool Tuning the Entity Bean Pool

Tuning WebLogic Server EJBs 10-3

10.2.2.3 Ready Bean Caching

For entity beans with a high cache miss ratio, maintaining ready bean instances can adversely affect performance. If you can set disable-ready-instances in the entity-cache element of an entity-descriptor , the container does not maintain the ready instances in cache. If the feature is enabled in the deployment descriptor, the cache only keeps the active instances. Once the involved transaction is committed or rolled back, the bean instance is moved from active cache to the pool immediately.

10.2.3 Tuning the Query Cache

Query Caching is a new feature in WebLogic Server 9.0 that allows read-only CMP entity beans to cache the results of arbitrary finders. Query caching is supported for all finders except prepared-query finders. The query cache can be an application-level cache as well as a bean-level cache. The size of the cache is limited by the weblogic-ejb-jar.xml parameter max-queries-in-cache. The finder-level flag in the weblogic-cmp-rdbms descriptor file, enable-query-caching is used to specify whether the results of that finder are to be cached. A flag with the same name has the same purpose for internal relationship finders when applied to the weblogic-relationship-role element. Queries are evicted from the query-cache under the following circumstances: ■ The query is least recently used and the query-cache has hit its size limit. ■ At least one of the EJBs that satisfy the query has been evicted from the entity bean cache, regardless of the reason. ■ The query corresponds to a finder that has eager-relationship-caching enabled and the query for the associated internal relationship finder has been evicted from the related beans query cache. It is possible to let the size of the entity-bean cache limit the size of the query-cache by setting the max-queries-in-cache parameter to 0, since queries are evicted from the cache when the corresponding EJB is evicted. This may avoid some lock contention in the query cache, but the performance gain may not be significant.

10.3 Tuning EJB Pools

The following section provides information on how to tune EJB pools: ■ Section 10.3.1, Tuning the Stateless Session Bean Pool ■ Section 10.3.2, Tuning the MDB Pool ■ Section 10.3.3, Tuning the Entity Bean Pool

10.3.1 Tuning the Stateless Session Bean Pool

The EJB container maintains a pool of stateless session beans to avoid creating and destroying instances. Though generally useful, this pooling is even more important for performance when the ejbCreate and the setSessionContext methods are expensive. The pool has a lower as well as an upper bound. The upper bound is the more important of the two. ■ The upper bound is specified by the max-beans-in-free-pool parameter. It should be set equal to the number of threads expected to invoke the EJB concurrently. Using too small of a value impacts concurrency. 10-4 Performance and Tuning for Oracle WebLogic Server ■ The lower bound is specified by the initial-beans-in-free-pool parameter. Increasing the value of initial-beans-in-free-pool increases the time it takes to deploy the application containing the EJB and contributes to startup time for the server. The advantage is the cost of creating EJB instances is not incurred at run time. Setting this value too high wastes memory.

10.3.2 Tuning the MDB Pool

The life cycle of MDBs is very similar to stateless session beans. The MDB pool has the same tuning parameters as stateless session beans and the same factors apply when tuning them. In general, most users will find that the default values are adequate for most applications. See Chapter 11, Tuning Message-Driven Beans .

10.3.3 Tuning the Entity Bean Pool

The entity bean pool serves two purposes: ■ A target objects for invocation of finders via reflection. ■ A pool of bean instances the container can recruit if it cannot find an instance for a particular primary key in the cache. The entity pool contains anonymous instances instances that do not have a primary key. These beans are not yet active meaning ejbActivate has not been invoked on them yet, though the EJB context has been set. Entity bean instances evicted from the entity cache are passivated and put into the pool. The tunables are the initial-beans-in-free-pool and max-beans-in-free-pool. Unlike stateless session beans and MDBs, the max-beans-in-free-pool has no relation with the thread count. You should increase the value of max-beans-in-free-pool if the entity bean constructor or setEnityContext methods are expensive.

10.4 CMP Entity Bean Tuning