This month I've decided to explore some of the more advanced performance enhancements that you can use if you are using EJB 2.0 on WebLogic. Our container-managed persistence (CMP) engine exposes several strategies for you to configure to get the most efficient - meaning least - use of your database. Field-groups allow you to specify which fields are loaded from the database together. Relationship caching tells the CMP engine to load the related bean when the parent bean is loaded. Cache-between-transactions allows you to cache the contents of entity beans between transactions against that bean. This is combined with Optimistic concurrency to get very good guarantees. Finally, there is ReadOnly concurrency, which gives you great performance with the ability to flush programmatically or through timeout. Using these optimization strategies, you will easily surpass the performance of naively written bean-managed persistence (BMP) entities and even exceed the performance of perfectly written J2EE-compliant BMP entities without the added maintenance and complexity that writing your own persistence layer can entail.

When you access a bean through a finder the CMP engine will by default load all the fields of the entity from the datastore. In many circumstances there are fields that you know you're not going to use in a certain code path; these fields need not be queried nor read from the database. Using field-groups you can specify which fields are to be loaded and the other fields will be loaded on demand. Field-groups do not stop you from eventually accessing the field and loading the data; it's just put off until the field is accessed by the application, or never loaded at all if you never access it. As a simple example, imagine a search application. The entities that you are searching for might contain the following fields: URL, Summary, Date, Keywords, and Cached Content. When you do your initial query of the database and return results for the user to look at, you probably don't want to load the cached content. It is a large field and if the user doesn't look at all of the results you're wasting a lot of work reading from the database.

In this example you would put the URL, Summary, and Date in a field-group and assign that group to the findByKeywords finder in the entity bean. When the finder was called, you'd get a collection of results with their designated fields prepopulated, and if the user happened to ask for the cached content the CMP engine would automatically go back out to the database and populate it. Some experimentation and benchmarking may be required to get the field-groups exactly right. Sometimes, if you misidentify which fields are really needed, you can reduce performance by not loading a field that is often used after the query. In order to activate this optimization you simply declare what groups each CMP field belongs to using the group-names attribute on the cmp-field entry and then associate a group with the finder using the group-name attribute.

Relationship Caching
Relationship caching is very important when the related data is usually used to access the parent bean. It reduces the number of SELECTs against the database by including the related bean fields in a SQL join. For one-to-one relationships this can offer a huge increase in performance because no extra work is done while you are reducing the SELECT statements. In the one-to-many case it will often depend on the fields present in your parent bean because under the join you will read those fields once for each related bean. I suggest that in this case you analyze the typical number of related beans and determine if it makes sense to take the extra per row performance hit in order to reduce the number of SELECT statements and the number of round-trips to the database.

As an example, if you have an Employee bean that also has a one-to-many relationship with Address beans, and when you access the Employee bean you often read the address data, you would probably enable this option because most Employee beans would have one or two related Address beans. In the case of the same Employee bean being related to PayrollStatement beans, you probably wouldn't want to enable relationship caching because the number of statements could be quite high and you would not be referencing them all every time you viewed the Employee bean.

Optimistic Concurrency
Perhaps the biggest performance increase you can get is by enabling cache-between-transactions and choosing Optimistic concurrency in uncontentious applications. Caching between transactions allows the CMP container to avoid returning to the database between every different use of the bean. Additionally, the application server will send out flushes on updates to the cached beans (even in a cluster) so that they will not be overly stale. With Optimistic concurrency enabled, any updates that are done have an included WHERE clause that checks to make sure that the row that is being updated hasn't been changed since the data was read from the database.

There are a number of options you can use to make this verification, including verifying that the read columns, the written columns, the version number, and the timestamp are the same. Each case has its own advantages but I would suggest that Version is probably the most universally applicable and may already be a column in your database. Column TYPE verification is the most expensive but the easiest to implement. To enable these optimizations you need to set the two flags on your bean and then change your update code to make sure that you handle the case when an OptimisticConcurrencyException might be thrown from a method that does an update or from an explicit commit statement for your bean-managed transaction.

ReadOnly Concurrency
Finally, there is ReadOnly concurrency, which implies caching between transactions. In this case, the data is only loaded from the database on the following conditions: the first read of the bean, the timeout has expired on the bean, or a programmatic flush of the bean was received. If you want to use ReadOnly beans and still occasionally change them, but don't want the overhead of Optimistic concurrency, you should have two beans that are backed by the same data - one ReadOnly and one normal EJB that can be updated. To programmatically flush your ReadOnly beans, simply cast the EJB home to weblogic.ejb.CachingHome and use the invalidate methods on that interface. For more extensive information on how to use these optimization strategies, please refer to http://edocs.bea.com/wls/docs70/ejb/index.html