10-2 Performance and Tuning for Oracle WebLogic Server
in heterogeneous clusters, where all EJBs have not been deployed to all WebLogic Server instances. In these cases, WebLogic Server uses a multitier connection to
access the datastore, rather than multiple direct connections. This approach uses fewer resources, and yields better performance for the transaction. However, for
best performance, the cluster should be homogeneous — all EJBs should reside on all available WebLogic Server instances.
10.2 Tuning EJB Caches
The following sections provide information on how to tune EJB caches:
■
Section 10.2.1, Tuning the Stateful Session Bean Cache
■
Section 10.2.2, Tuning the Entity Bean Cache
■
Section 10.2.3, Tuning the Query Cache
10.2.1 Tuning the Stateful Session Bean Cache
The EJB Container caches stateful session beans in memory up to a count specified by the max-beans-in-cache parameter specified in weblogic-ejb-jar.xml. This
parameter should be set equal to the number of concurrent users. This ensures minimum passivation of stateful session beans to disk and subsequent activation from
disk which yields better performance.
10.2.2 Tuning the Entity Bean Cache
Entity beans are cached at two levels by the EJB container:
■
Section 10.2.2.1, Transaction-Level Caching
■
Section 10.2.2.2, Caching between Transactions
■
Section 10.2.2.3, Ready Bean Caching
10.2.2.1 Transaction-Level Caching
Once an entity bean has been loaded from the database, it is always retrieved from the cache whenever it is requested when using the findByPrimaryKey or invoked from
a cached reference in that transaction. Getting an entity bean using a non-primary key finder always retrieves the persistent state of the bean from the data base.
10.2.2.2 Caching between Transactions
Entity bean instances are also cached between transactions. However, by default, the persistent state of the entity beans are not cached between transactions. To enable
caching between transactions, set the value of the cache-between-transactions parameter to true.
Is it safe to cache the state? This depends on the concurrency-strategy for that bean. The entity-bean cache is really only useful when cache-between-transactions
can be safely set to true. In cases where ejbActivate and ejbPassivate callbacks are expensive, it is still a good idea to ensure the entity-cache size is large
enough. Even though the persistent state may be reloaded at least once per transaction, the beans in the cache are already activated. The value of the cache-size is
set by the deployment descriptor parameter max-beans-in-cache and should be set to maximize cache-hits. In most situations, the value need not be larger than the
product of the number of rows in the table associated with the entity bean and the number of threads expected to access the bean concurrently.
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
