The Promise of Entity Beans @ WEBLOGIC JOURNAL

The Promise of Entity Beans

Working as a BEA consultant, I've helped customers successfully design and deploy applications on various versions of the WebLogic Server (WLS). BEA has been supporting container-managed persistence (CMP) entity beans since EJB 1.0, and a few of our customers have used them. Unfortunately, some used them without understanding the ramifications; others heard about performance constraints and completely excluded entity beans from their architecture/design choices.

It was difficult to come up with reasons to use CMP entity beans when chief architects asked, "When should I consider using CMP entity beans at all?" The nirvana of entity beans lies in two things: caching and object-relational mapping. Both were done poorly in the earlier implementations, but EJB 2.0 came to the rescue. WLS 7.0's add-on features to the EJB 2.0 specification bridge the gap in performance between using entity beans and using stateless session beans with DAO and JDBC - in some cases even performing faster than the latter. When using JDBC, developers are strongly advised to use container-managed transactions.

Problems with Earlier Versions
Several customers who used entity beans in the past had to redesign and use JDBC because their systems were too slow to meet service-level agreements. That slowness was due to some of the following problems:

No caching: Each transaction went to the database to load the entity bean. One of the promises customers look for in using entity beans is caching, and none was available for regular entity beans in a clustered environment.

Single-table support (O-R mapping too simplistic): Customers were also looking for object-relational mapping to be done by the entity bean, but the mapping provided by the container was too simplistic.

Single instance of the entity bean per virtual machine (VM): Because WebLogic 5.1 and below only supported exclusive locking, all the calls to the entity bean were serialized, causing bottlenecks even for read-only beans.

Exclusive locking: Deadlocks were highly likely when some beans used transactions and some did not.

Single setX call: This caused the entire entity bean to be written to the database. Before the EJB 2.0 specification, the container didn't have any hooks for determining what changed and what didn't. This meant that on an ejbStore, all the attributes were updated.

Loading: Loading the entity bean caused all data members to be loaded in memory, even if only a couple were needed.

No dynamic queries: EJB had to be redeployed to write a new query.

Queries: Queries can instantiate large numbers of entity beans, consuming memory and degrading performance.

WLS 7.0 Features
WLS 7.0 implements the EJB 2.0 specification, providing for richer object-relational mapping. EJB 2.0 also provides the container with a lot more flexibility for doing optimized reads and writes to the database. The following features elucidate the richness and flexibility developers have in designing entity beans in WLS 7.0.

Container-managed relationships: Entity beans can have relationships with other beans; these relationships can be either bidirectional or unidirectional. WLS supports three types of relationship mappings managed by WebLogic CMP: one-to-one, one-to-many, and many-to-many.

Multiple table mapping to an entity bean: Multiple table support allows an implementer of EJB 2.0 CMP beans to map a single EJB to multiple DBMS tables within a single database.

Tuned writes with EJB 2.0: Instead of writing all the fields to the database when ejbStore is called, only the updated fields are written to the database.

Tuned reads using field groups: On an ejbLoad the container, instead of loading all the fields of the entity bean, loads only fields in the field-group.

Caching of relationships: This feature increases entity bean performance by loading related beans into the cache in a single join query instead of multiple queries.

Entity beans can return ResultSets: WLS supports ejbSelect() queries that return the results of multicolumn queries in the form of a java.sql.ResultSet.

Application-wide cache for heterogeneous entity beans: Instead of a separate cache for each entity bean, this feature enables multiple entity beans within an EAR to share a single runtime cache.

Dynamic queries: The EJB 2.0 specification forces users to hard-code queries in the deployment descriptor. With dynamic queries, new queries can be constructed and executed programmatically without redeploying the beans.

Read-mostly design pattern: In the real world, most applications are 90% read and 10% update. An entity bean can be written to model the data and can be deployed as both a read-only entity bean and a regular entity bean. With this approach, users who want to read data talk to the read-only entity bean, and users who want to update data talk to the regular entity bean. When an update occurs, the container invalidates all the read-only entity beans, forcing the container to call ejbLoad the next time the data is accessed.

Other useful features include automatic primary key generation, cascade delete support, EJB QL support, ejbSelect methods, and the concurrency strategies described below.

Concurrency Strategies
A concurrency strategy defines how many instances of an entity bean are created, who does the locking to maintain transactional integrity, and the access pattern of the data modeled in the entity bean. The right concurrency strategy can make a tremendous difference in the performance of your entity beans.

Exclusive: The container creates only one instance of an entity bean per VM, and all calls to the entity bean are serialized as the container locks the entity bean on use (for both read and write). This is never recommended.

Database: The container defers locking to the database, and each transaction gets its own copy of the entity bean. ejbLoad and ejbStore are called at the beginning and end of the transaction respectively.

Read-only entity beans: Neither the database nor the container holds any locks, and each transaction gets its own copy of the entity bean. A configurable parameter called <read-timeout-seconds> controls when ejbLoad is called on the entity bean. ejbStore is never called on the entity bean. Clients can still call create, remove, and update operations on the entity beans. The creation and removal will be successful, but the updates won't modify the database because ejbStore isn't called. It's the programmer's responsibility to not call CUD (create,update,delete) methods on read-only entity beans. Read-only entity beans are a perfect solution to the "distributed cache" problem.

Optimistic entity beans: The container defers locking to the database, but locks aren't held during the transaction. The basic idea is that the container checks for modified data before committing and rolls back if someone else has modified it. This is useful if you want higher consistency than TX_READ_COMMITTED but don't want to go as high as TX_SERIALIZABLE. Use it if you can live with reading stale data for a short time but want complete transactional integrity for updates. There are four options for checking optimistic conflicts: 1. Check columns that were read 2. Check columns that were modified 3. Check timestamp column 4. Check a version column

Options 3 and 4 aren't recommended because the schema of the table needs to be changed to incorporate this concurrency strategy. Also, with the optimistic concurrency strategy, you can configure whether you want caching between transactions to be true or false. With caching between transactions set to false, ejbLoad will be called at the beginning of each transaction.

Comparison
With CMP, there will always be additional processing due to the integration of the EJB container and a layer of container-generated code-handling transactions, security, pooling, life-cycle management, failover, caching, and relationships. CMP (by design or by spec) has to do internal operations, (ejbLoad, ejbStore, ejbActivate, ejbPassivate) as opposed to JDBC logic manually programmed by developers. The benefits of the container infrastructure are optimized, generated database access; accelerated development; and simplified code maintenance.

On the benchmarks I've seen, unless the data is cached, [stateless session bean + DAO (doing JDBC)] has performed 30-50% faster than the entity bean implementation.

When to Use What
Entity beans shouldn't be used as a substitute for writing JDBC. Use entity beans if your object-relational model isn't overly complex (involving numerous joins, etc.) and flexibility and code maintenance are more important than raw speed for your project.

Use JDBC for simplistic, atomic-blind updates; to integrate with stored procedures and triggers; and to handle large ResultSets.

WebLogic add-ons such as the read-mostly design pattern and optimistic caching with cache-between-transactions set to true are two design choices that make entity beans an attractive option. Both are BEA-proprietary, and both are specified in the WebLogic-specific deployment descriptor. No code changes are needed when migrating to another J2EE-compliant application server. Use optimistic caching concurrency strategy if it's OK for the application to read stale data for a short period of time.

Use the read-mostly design pattern for the use case in which you read most of the time and update less frequently. This design pattern also has the shortcoming that the readers can read stale data. In case some of the readers should not read stale data at all, they can be made to read from the read-write bean.

Read-only entity beans for CMP entity beans are mentioned in the features deferred to future releases of the EJB specification. Use read-only entity beans to implement a distributed cache that can be refreshed periodically.

Conclusion
Most real-world applications do far more reads than writes. Implementing the read-mostly pattern will provide the best of both worlds. It provides easy development and flexible deployment, along with excellent performance characteristics for accessing data and paying extra overhead only when data is being modified. Optimistic concurrency with cache-between-transactions set to true can be faster than JDBC. Writing optimized SQL is hard for regular Java programmers, so don't ignore entity beans - evaluate and determine whether they're a good fit.

Entity Beans Examples
Examples are provided in subdirectories of BEA-HOME/samples/server/src/ejb20.

For an example that demonstrates the relationships, look at the BEA-HOME/samples/server/src/ejb20/relationships/bands directory.

For an example that demonstrates multiple table mapping, look at the BEA-HOME/samples/server/src/ejb20/multitable directory.

To use the database concurrency option specify <concurrency-strategy>Database</concurrency-strategy> in the weblogic-ejb-jar.xml. weblogic-ejb-jar.xml To use the read-only concurrency option, specify <concurrency-strategy>Read-Only</concurrency-strategy> in the weblogic-ejb-jar.xml.

To use the optimistic concurrency with cache-between-transactions and check on Modified option specify <concurrency strategy>Optimistic</concurrency-strategy> <cache-between-transactions>True</cache-between-transactions> in the weblogic-ejb-jar.xml and specify <verify-columns>Modified</verify-columns> in the weblogic-cmp-rdbms-jar.xml.

To implement the "read-mostly" design pattern register the bean implementation as two EJBs, one as read-only and the other as Read-Write, and add the <invalidate>ejb-name</invalidate> where ejbname is the read-only entity bean name in the weblogic-ejb-jar.xml.

References

http://edocs.bea.com/wls/docs70/ejb/index.html

http://java.sun.com/products/ejb/docs.html

About Vijay Mandava
Vijay Mandava joined BEA as a technical manager in the Professional Services organization in 1999. He now works as a principal systems engineer in the Systems Engineering organization. Vijay is a Sun certified Java programmer and a BEA certified Weblogic Server developer.