Performance-Tuning Entity Beans

(from Mastering EJB2)

There is a great deal of fear, uncertainty, and doubt (FUD) in the industry
about entity beans. Many organizations are using them improperly, creating
performance issues. Here are some tips and tricks to make your entity beans
high performing:

■ Entity beans should not be called directly from remote clients, but rather
  from session or entity beans located in the same process. Because of this,
  you should always call entity beans through their local interfaces, not
  their remote interfaces.
 
■ Use your container's caching options as much as possible. If your beans
  are read-only, instruct your container to keep them cached permanently. If
  they are read-mostly or read-write, many containers have algorithms to
  deal with this. Remember: Memory is cheap.

■ Be sure your transactions run on the server, are as short as possible, and
  encapsulate all of the entity bean operations you'd like to participate in
  that transaction. This is important because the JDBC occurs at the begin-
  ning and end of transactions. If you have a transaction occurring for each
  entity bean get/set operation, you are performing SQL hits on each
  method call. The best way to perform transactions with entity beans is to
  wrap all your entity bean calls within a session bean method. Deploy both
  the session and entity beans with the container-managed transaction
  attribute of Required. Ths creates a transaction in the session bean that
  encapsulates all entity beans in the same transaction.

■ Consider having your container batch JDBC updates all at once at the end
  of the transaction. That way, if you perform many JDBC operations in a
  single transaction, you only need one network call to the database.
 
■ For performance, use container managed persistence, if possible. As con-
  voluted as it may sound, container managed persistence can actually be
  higher-performing than bean managed persistence. Just make sure that
  you're using a good persister that gives you great flexiblity when
  performing O/R mapping.

■ If you are not going to access your entire entity bean's data on each trans-
  action, lazy-load some of your fields rather than loading it all when the
  entity bean is first accessed. You can lazy-load your fields programmati-
  cally using BMP by fine-tuning your JDBC code, or you can lazy-load
  your fields declaratively using CMP if your container tools support it.
 
■ If you'r using CMP, instruct your container to persist fields in bulk. For
  example, BEA Weblogic has the notion of field groups. This empowers
  you to define groups of fields (even across relationships) that persist
  together, reducing the amount of SQL required.

■ If you're using CMP, use your container tools to force the container to
  have your finder methods automatically load your bean, rather than hav-
  ing finders and loading happen separately, resulting in two SQL state-
  ments. The only time you should not do this is if you're not going to read
  data from your entity bean (for example, setting fields, but not getting
  fields).
 
■ Send output to a good loggin/tracing system, such as a loggin
  message-driven bean. This allows you to understand the methods that
  are causing bottlenecks, such as repeated loads or stores.
 
■ Use a performance-profiling toll to identify bottlenecks, such as Opti-
  mizeIt or JProbe. If your program is hanging on the JDBC driver, chances
  are the database is your bottleneck.
 
Performance-tuning your entity beans opens up the possibility to create fine-
grained entity beans that model a single row in the database, as well as coarse-
grained entity beans that model a complex set of data spanning multiple tables.