18.7 Performance Checklist

The performance of EJB-based J2EE systems overwhelmingly depends on getting the design right. Use performance-optimizing design patterns: Value Object, Page-by-Page Iterator, ValueListHandler, Data Access Object, Fast Lane Reader, Service Locator, Verified Service Locator, EJBHomeFactory, Session Façade, CompositeEntity, Factory, Builder, Director, Recycler, Optimistic Locking, Reactor, Front Controller, Proxy, Decorator, and Message Façade.

Explicitly remove beans from the container when a session is expired. Leaving beans too long will get them serialized by the container, which can dramatically decrease performance.

Coarse-grained EJBs are faster. Remote EJB calls should be combined to reduce the required remote invocations.

Design the application to access entity beans from session beans.

Collocated EJBs should be defined as Local EJBs (from EJB 2.0), collocated within an application server that can optimize local EJB communications, or built as normal JavaBeans and then wrapped in an EJB to provide one coarse-grained EJB (CompositeEntity design pattern).

EJBs should not be simple wrappers on database data rows; they should have business logic. To simply access data, use JDBC directly.

Stateless session beans are faster than stateful session beans. If you have stateful beans in your design, convert them to stateless session beans by adding parameters that hold the extra state to the bean methods.

Optimize read-only EJBs to use their own design, their own application server, read-only transactions, and their own optimal configuration.

Cache JNDI lookups.

Use container-managed persistence (CMP) by default. Profile the application to determine which beans cause bottlenecks from their persistency, and implement bean-managed persistence (BMP) for those beans.

Use the Data Access Object design pattern to abstract your BMP implementations so you can take advantage of optimizations possible when dealing with multiple beans or database-specific features.

Minimize the time spent in any transaction, but don't shorten transactions so much that you are unnecessarily increasing the total number of transactions. Combine transactions that are close in time to minimize overall transaction time. This may require controlling the transaction manually (i.e., turning off auto-commit for JDBC transactions or using TX_REQUIRED for EJBs).

J2EE transactions are defined with several isolation modes. Choose the lowest-cost transaction isolation level that avoids corrupting the data. Transaction levels in order of increasing cost are: TRANSACTION_READ_UNCOMMITTED, TRANSACTION_READ_COMMITTED, TRANSACTION_REPEATABLE_READ, and TRANSACTION_SERIALIZABLE.

Don't leave transactions open, relying on the user to close them. There will inevitably be times when the user does not close the transaction, and the consequent long transaction will decrease the performance of the system significantly.

Bulk or batch updates are usually more efficiently performed in larger transactions.

Lock only where the design absolutely requires it.

Beans.instantiate( ) incurs a filesystem check to create new bean instances in some application servers. Use the Factory pattern with new to avoid the filesystem check.

Tune the message-driven beans' pool size to optimize the concurrent processing of messages.

Use initialization and finalization methods to cache bean-specific resources. Good initialization locations are setSessionContext( ), ejbCreate( ), setEntityContext( ), and setMesssageDrivenContext( ); good finalization locations are ejbRemove( ) and unSetEntityContext( ).

Tune the application server's JVM heap, pool sizes, and cache sizes.