Tuning EJB Applications

The EJB container in WebLogic Server specifies an additional deployment descriptor file named weblogic-ejb-jar.xml , which contains parameters that define the concurrency, caching, clustering, and transaction behavior. These parameters can be tuned to achieve optimum performance for your EJB applications. This section describes the parameters that can be tuned for each type of EJB.

Stateless Session Beans

WebLogic Server maintains a free pool of bean instances for every stateless session bean. When a remote method is called on a stateless session bean, the EJB container picks a bean instance from the free pool and executes the remote method on it. On completion of the method execution, the bean instance is returned to the free pool. Because all stateless session bean instances are equal and because they do not have any state, it does not matter which instance is picked from the free pool. The EJB container in WebLogic Server thus saves time that would be wasted in creating a new stateless session bean instance each time a remote method is called. Pooling allows the EJB container to serve a large number of clients using a small number of bean instances.

The behavior of the free pool is controlled by two parameters: initial-beans-in-free-pool and max-beans-in-free-pool . These parameters are defined within the weblogic-ejb-jar.xml file. You need to tune these parameters to get good performance for your stateless session beans.

The initial-beans-in-free-pool parameter defines the number of bean instances the EJB container will create when the stateless session EJB is deployed to the server. Creating the bean instances immediately after deployment allows the container to immediately service remote method requests without having to instantiate new bean instances.

The max-beans-in-free-pool parameter defines the maximum number of stateless session bean instances in the free pool. This parameter puts an upper limit on the number of bean instances and controls the amount of concurrency that can be achieved with stateless session beans. When a remote method request arrives at the EJB container, the container grabs a bean instance from the free pool. If there are no free instances in the pool, the container will create one until the number reaches the max-beans-in-free-pool limit. If this upper limit is reached, the EJB container will wait until another bean instance becomes free and is released back to the pool.

As the remote method of each bean instance is executed in a WebLogic Server execute thread, the maximum concurrency is actually controlled by the number of available execute threads. By default, there is no limit to the number of instances the container will create. In most cases, it is recommended that you not tune the max-beans-in-free-pool parameter, which will let the EJB container create new instances as needed.

Under certain circumstances, however, you might need to set this limit. If your stateless session bean has a member variable that holds a connection to an external legacy system, and if the number of connections that can be established with the external system is limited, you should set the max-beans-in-free-pool parameter to the maximum number of connections that can be created. In this case, the max-beans-in-free-pool parameter can be used to limit the use of resources.

Note

The initial-beans-in-free-pool and max-beans-in-free-pool parameters work in the same way for message-driven beans also.

When you're using clustered stateless session beans, if the EJB contains idempotent methods , you should set the stateless-bean-methods-are-idempotent flag to true in the weblogic-ejb-jar.xml file. Idempotent methods are methods that can be called multiple times and produce the same result as if the methods were called only once. Setting this flag to true enables the smart EJB stub to fail over to another server hosting the bean in case the server that was executing the remote method failed.

Stateful Session Beans

A stateful session EJB instance maintains state and is associated with a client that created it. There is a one-to-one correspondence between the clients and the bean instances on the server. Because each client has a reference to a specific stateful session bean instance on the server, there is no concept of pooling in the case of stateful session EJBs.

Because each client has its own stateful session bean instance on the server, when the number of clients grows large, so does the number of bean instances on the server. It is not always feasible to maintain all the bean instances in memory for the lifetime of a client. The EJB container is thus required to manage an active set of stateful session beans through mechanisms known as activation and passivation .

For more information on the activation and passivation mechanisms for stateful session beans, see Chapter 20.

Activation and passivation mechanisms allow the EJB container to maintain a working set of stateful session bean instances in memory and thus conserve the server's memory resources. The max-beans-in-cache parameter in the weblogic-ejb-jar.xml deployment descriptor is used to configure the maximum number of stateful session bean instances that can be held in the in-memory cache.

Setting the max-beans-in-cache parameter to a low value limits the maximum number of active bean instances that the EJB container can hold in the cache, thus leading to excessive activation and passivation as more beans are created. Activation and passivation of beans are expensive operations and can certainly slow down performance. Setting this parameter to a high value can put unnecessary strain on the server's memory resources. You need to tune this parameter appropriately based on factors such as the maximum heap available for the server, average life period of the stateful session bean, as well as the maximum number of stateful session bean requests.

Entity Beans

Entity beans are EJBs that provide an object view of data in the database. The state of an entity bean is transactional, and updates are persisted to the database only if the transaction commits. If the transaction rolls back, the bean returns to its last committed state.

Note

Entity beans are described in detail in Chapter 21, "Managing Persistence with Entity Beans."

Tuning Pool Size for Entity Beans

WebLogic Server maintains a pool of entity beans that do not have an identity; for example, they do not have a primary key associated with them. Beans in this pool are used to invoke finder methods as well as home methods such as create and remove . The max-beans-in-free-pool parameter controls the number of anonymous instances in the free pool. If your clients create many entity beans or call finder methods a lot, increasing this number will improve performance. Set this parameter depending on the heap available for WebLogic Server.

Using the Appropriate Concurrency Strategy

WebLogic Server allows the user to select a concurrency control strategy for the entity beans. It provides four kinds of concurrency strategies for entity beans: Database, Exclusive, Optimistic, and ReadOnly.

The Concurrency strategy for the entity beans can be specified using the concurrency-strategy parameter in the weblogic-ejb-jar.xml file. The default strategy is database concurrency.

Database concurrency strategy improves concurrency by deferring lock management and deadlock detection to the database. In this kind of concurrency model, two clients can call the same entity bean (for example, an entity bean with the same primary key) in two separate transactions. If the two beans are modifying the same data at the same time, the database detects and resolves the conflict by rolling back one of the transactions. If the entity bean has been called by the clients for a read operation, this concurrency strategy provides the best performance because it allows the two transactions to proceed at the same time.

When using database concurrency strategy, the ejbLoad() method is called at the start of each transaction to obtain the most current EJB data.

Exclusive locking limits the concurrency because, in this case, the EJB container has a lock on the bean instance, and there can be only a single bean instance per primary key. As a result, there can be only one transaction active for an entity bean instance at a time, even in the case of a read operation.

When you're using the exclusive locking behavior in a single server environment, consider using the cache-between-transactions parameter to limit the ejbLoad() method being called at the start of each transaction. By default, ejbLoad() is called at the start of each transaction as other sources may also be updating data. However, while using exclusive concurrency in a single server environment, there will be no other clients updating the data, so you can be assured that the cached EJB data is always up to date. You can set this parameter to true in weblogic-ejb-jar.xml to limit calls to ejbLoad() . In a clustered environment, the cache-between-transactions parameter is automatically disabled because the entity bean on any server in the cluster can update the data.

The Optimistic concurrency strategy does not hold any locks in the EJB container or the database. To enable the use of this strategy, you must specify the verify- columns attribute in the weblogic-cmp-rdbms-jar.xml deployment descriptor. In this case, the EJB container ensures that the data being updated by a transaction has not been modified by some other client.

For more information on the concurrency strategies available for entity beans, see "Choose the Right Concurrency Strategy," p. 762 .

The ReadOnly concurrency strategy creates an instance of a read-only entity bean for each transaction. This allows each transaction to proceed in parallel and improves concurrency. Also, to minimize reading data from the database, the EJB container copies the state from an existing instance in the cache while allocating a new instance after checking that the data is up-to-date. Using this strategy with ReadOnly entity beans provides good performance.

Using the Appropriate Transaction Isolation Level

The transaction isolation level defines the degree to which concurrent transactions accessing the database are isolated from each other for read operations. Setting lower isolation levels provides you with better concurrency between transactions accessing the database, at the cost of lesser isolation between transactions. Set the isolation level appropriately depending on your application and choice between concurrency and isolation.

Using Delay-Database-Insert-Until

The Delay-Database-Insert-Until attribute of the weblogic-cmp-rdbms-jar.xml file allows you to control when and how the EJB container inserts newly created beans in the database. The attribute can have three values: ejbCreate , ejbPostCreate , and commit .

The default value is ejbPostCreate , which means that the data will be inserted immediately after the ejbPostCreate() method. If you modify any of the bean's fields in the ejbPostCreate method, setting the Delay-Database-Insert-Until attribute to ejbPostCreate will save an extra ejbStore() operation. If you do not modify any fields in the ejbPostCreate method, you may specify the value to ejbCreate .

You can specify the Delay-Database-Insert-Until value as commit and improve performance of CMP entity bean creation. This feature is known as bulk insert , and it allows the container to create multiple database inserts in just one SQL statement. As a result, multiple database insert calls are avoided and performance improved. Bulk insert applies only to inserts between a transaction marked by begin() and commit() .