| By Vijay Mandava |
Article Rating: |
|
| August 23, 2002 12:00 AM EDT |
Reads: |
12,746 |
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
Subscribe to Weblogic Journal Email News Alerts
Subscribe via RSS
