Show TOC

 Optimizations and Performance TuningLocate this document in the navigation structure

Use

The J2EE Engine provides different options for optimizing your EJB applications. The positive result from these optimizations depends on your application specifics and logic.

Features

Read-Only Container-Managed Entity Beans

When you design your applications, we recommend that you determine the persistent data, which will not be updated, and if possible encapsulate it in read-only entity beans.

Read-only container-managed beans can be used to work with the persistent data when the client does not need to update the data.

Read-only container-managed beans have several advantages:

  • They do not lock entities in the database
  • If the bean attempts to change information in the database, the system will throw an exception
  • They are loaded once, and until they are kept in the cache they are neither loaded, nor stored in the database, which makes their handling lighter.

For more information about defining a container-managed entity bean as read-only, see Defining Entity Beans as Read-Only .

Choosing the Right Locking Strategy

To achieve a balance between the performance and isolation requirements, you have to:

  • Determine which entity beans will use database locking and which Enqueue Server locking
  • Choose very carefully the appropriate isolation levels for the beans that use Enqueue Server locking. For more information, see Isolation Levels .
  • Choose the finder methods that will set locks.

For more information, see Locking .

Optimizing the Finder Methods

The EJB Container stores in the database all updates made by a transaction before a finder method is executed and thus guarantees that the changes are visible to the finder query. To increase the finder methods' performance, this operation can be switched off by including the <switch-off-storing/> element for the corresponding finder/select method in persistent.xml.

Additionally, you can decrease the number of database access calls by specifying the <load-selected-objects/> element for finder/select methods in persistent.xml. This option loads in the cache all objects selected by the finder method and if specified, locks the objects. The operations, performed afterwards, use the loaded objects, which avoids the overhead from the additional loading of each object. However, you must take into consideration whether you will use the loaded entities afterwards, because the execution of the finder query is slower and the cache may overflow if there are too many loaded objects.

For more information about setting these deployment properties, see Specifying the Deployment Properties of Finder/Select Methods .

For more information about the additional optimization properties of the finder methods (<fetch-size> and <load-selected-objects> ), see persistent.xml .

Tuning the Pool Properties

The pool properties are a useful way of balancing between performance and memory usage. The number of instances in the pool, if carefully determined, may improve the performance of your enterprise beans. For more information, see Pool Properties .