Java Reference
In-Depth Information
Chapter 22:
Container-Managed Persistence
In This Chapter
Extending the discussion in
previous chapter
,
in this chapter you will learn the container managed
persistence in details. You also see how the EJBs developed since
Chapter 20
can be put together to
build a simple application.
CMP Entity Bean — a Rebirth after EJB2.0
The term
container-managed persistence
means that the EJB container handles all database access
the entity bean requires. The bean's code contains no database-access (SQL) calls. As a result, the
bean's code is not tied to a specific persistent storage mechanism (database). Because of this flexibility,
even if you redeploy the same entity bean on different J2EE-compliant application servers that use
different types of databases, you will not need to modify or recompile the bean's code. In short, your
entity beans are more portable and easier to develop.
It sounds like a very nice concept. However, in the early stage of EJB adoption (up to EJB specification
version 1.1), CMP entity beans have been labeled as slow or even as a performance nightmare. The
persistent state was stored as bean-instance variables, and bean developers often had to use third-
party tools to map bean attributes to database fields (the so called O/R mapping). The integration
between such tools and application servers had given developers enough headaches. It was also
difficult to handle relationships between related objects such as
Orders
and
Line-Items
.
Fortunately, all these problems have been addressed in the EJB 2.0 specification released in
September 2001. With EJB 2.0, the EJB container uses the information that bean developers provide in
the entity bean's abstract schema to generate all the data-access calls. As part of an entity bean's
deployment descriptor, the abstract schema defines the bean's persistent fields as well as relationships.
The term
abstract
distinguishes this schema from the physical schema of the underlying data store.
Bean developers specify the name of an abstract schema in the deployment descriptor. This name is
referenced by queries written in the Enterprise JavaBeans Query Language (EJB QL). For a CMP entity
bean, you must define an EJB QL query for every
finder
method (except
findByPrimaryKey
). The
EJB QL query determines the database query the EJB container executes when the
finder
method is
invoked. You see the examples of EJB QL later in this chapter.
There are two types of container-managed fields in a CMP bean:
persistent
and
relational
. The
persistent fields of an entity bean are stored in the underlying data store. Collectively, these fields
constitute the state of the bean. At runtime, the EJB container automatically synchronizes this state with
the database. During deployment, the container typically maps the entity bean to a database table and
maps the persistent fields to the table's columns.
A relationship field is like a foreign key in a database table — it identifies a related bean. Like a
persistent field, a relationship field is virtual and is defined in the enterprise bean class with access
methods. But unlike a persistent field, a relationship field does not represent the bean's state.
According to EJB 2.0 specification, the implementation classes for CMP beans must be abstract. That
means no instance of these implementation classes can be directly instantiated. The EJB container
generates a concrete class based on the code you have written and all the information you have
provided in the deployment descriptor. These concrete classes contain all the database-access calls
that deal with the persistent state as well as the relationship between business entities. Instances of
such concrete classes are instantiated during runtime and invoked by the client. The generation and
instantiation of such concrete classes are totally transparent to bean developers and client
programmers.
To further boost the performance, EJB 2.0 also introduced the local (both home and remote) interfaces
that provide support for lightweight access by local clients. The local interfaces are standard Java
interfaces that do not inherit from RMI. When a client (it may be another EJB) accesses the EJB on the
