Entity Bean Performance

Using entity beans will probably produce worse performance than leading alternative approaches to persistence, unless your application server has an efficient distributed and transactional entity bean cache, or substantial developer effort is put into multiple deployments. In the latter case, performance will be determined by the nature of the application; applications with largely read-only access to data will perform well, while those with many writes will gain little benefit from caching.

Why does this matter? Because entity bean performance, without effective caching, may be very bad indeed.

Efficient performance from the entity bean model rests on the following conditions:

• Data is likely to be modified (and not simply read) when it is accessed. Excepting proprietary support for read-only entities, entity beans assume a read-modify-write model.

• Modification occurs at the individual mapped object level, not as an aggregate operation (that is, updates can efficiently be done with individual objects in Java rather than to multiple tuples in an RDBMS).

Why do entity beans have performance problems in many cases?

• Entity beans use a one-size fits-all approach. The entity bean abstraction may make it impossible to access persistent data efficiently, as we've seen with RDBMSs.

• The entity bean contract is rigid, making it impossible to write efficient BMP code.

• It's hard to tune entity bean data access, whether we use BMP or CMP.

• Entity beans have considerable run-time overhead, even with the use of local, rather than remote, interfaces. (If no security roles or container transactions are defined for an EJB in its deployment descriptor element, many application servers may skip transaction and security checks when instances of the bean are invoked at run time. When combined with local calling, this can remove much of the overhead of entity beans. However, this is not guaranteed to happen in all servers, and an entity bean will always have a much higher overhead than an ordinary Java class.)

• Entity bean performance in practice often comes down to O/R mapping performance, and there's no guarantee that a J2EE application server vendor has strong expertise in this area.

Entity beans perform particularly badly, and consume excessive resources, with large resultsets, especially if the resultsets (like search results) are not modified by users. Entity beans perform best with data that's always modified at the individual record level.