Container-Managed Persistence

CMP means that the EJB container is responsible for implementing the persistence functionality of the entity bean. The state of the bean and the data in the database are maintained in sync by the EJB container. The EJB container determines when to refresh the entity bean contents with data in the database and when to refresh the data in the database with the contents of the entity bean. The bean provider is freed up from incorporating this persistence functionality, that is, having to write the SQL queries to either retrieve, insert, update, or delete data in the database.

How does the EJB container know which database tables to go against to generate the SQL queries to persist or retrieve the data?

Because entity beans represent a snapshot of the data in the database, there exists a mapping between the entity bean and the database tables. The bean provider defines the field mapping between the entity bean and database tables. This mapping enables the EJB container to understand the tables and columns with which the SQL queries need to interact. Based on this information, the tool provided by the EJB container generates a set of classes with embedded SQL statements to interact with the database.

There are two types of field mappings available in the EJB 2.0 specification:

• Container-managed persistence (CMP) fields The CMP fields represent a mapping between the entity bean's fields and the columns of the database tables.

• Container-managed relationship (CMR) fields The CMR fields represent the mapping between the foreign key columns of the tables in the database.

CMP is not about just mapping fields in the entity bean to database table columns, which, by the way, is relatively simple to achieve. The primary area of concern is the object-to-relational (O/R) mapping that causes major headaches in enterprise applications. The root cause of this is the way that objects and data are organized in databases. Objects are inherently hierarchical in nature, in other words, they have a distinct object hierarchy.

Databases (such as Oracle, Sybase, Informix, and so on that you commonly deal with in enterprise applications), on the other hand, are relational in nature. This causes a disconnect when you try to persist or retrieve relational data to hierarchical objects. The EJB 2.0 specification addresses this by defining the CMR fields, which are logical fields that encapsulate the relationship data between entity beans. In the following section, you will take a closer look at relationships supported by CMP.

CMP Relationships

Entity beans can represent relationships between multiple tables in the database as well. Relationships between entity beans, which are similar to the relationships between database tables, can be one of three types:

• One-to-one A one-to-one relationship represents a relationship between the primary key of one entity bean with the foreign key of another entity bean. This relationship between entity beans represents a relationship between two tables in the database.

• One-to-many A one-to-many relationship represents a mapping between the primary key of one entity bean with the foreign keys of a number of beans.

• Many-to-many The most complex of relationships is the many-to-many relationship. Because many-to-many relationships are represented in the database as join tables, the many-to-many relationship represents the mapping between the join table and the primary keys of the two entity beans participating in the join relationship.

Apart from these three types of relationships, there are two variations of these relationships: unidirectional and bidirectional.

A unidirectional relationship can navigate in only one direction and is generally used by remote entity beans, that is, beans participating in a relationship but not part of the same Java archive file. A unidirectional relationship implies that of the two entity beans participating in the relationship, one entity bean knows about the second entity bean but not vice versa. This knowledge about each other is defined in the deployment descriptor file.

A bidirectional relationship can navigate in both directions and normally is used by beans that are part of the same Java archive file. In a bidirectional relationship, both entity beans participating in the relationship are aware of each other. This knowledge about each other is defined in the deployment descriptor file.

Relationships in entity beans are implemented as get()XXX/set()XXX methods. Depending on the cardinality of the relationship (one-to-one, one-to-many, and so on) the return type of these get()XXX/set()XXX methods can be either a single object or a collection of objects (using the java.util.Collection API) representing the container-managed relationship fields.

Note

In the EJB 2.0 specification, a container-managed entity bean is defined as abstract and its persistent fields are not defined directly in the bean class. Instead, an abstract persistent schema is developed that lets the bean provider declare the persistent fields and bean relationships indirectly.

An abstract persistence schema is specified in the deployment descriptor file for each entity bean and all dependent objects.

Another concept that you need to be familiar with when studying CMP is that of dependent objects and dependent values. Now you will have a look at these concepts.

Dependent Objects and Values

Dependent objects are objects that are managed by another entity bean. Because entity beans carry a performance overhead, it is not feasible to implement all business objects as entity beans. It is far more beneficial to implement coarse-grained business objects as entity beans and fine-grained objects as dependent objects. Dependent objects have an abstract persistent schema similar to entity beans but are not available for access outside the EJB container. Their life cycles are handled by the entity bean or another dependent object.

Tip

From a database designer's perspective, weak entities are potential candidates for modeling as dependent objects.

For example, if a customer is an entity bean then it is recommended that you define the customer's address as a dependent object rather than an address entity bean.

A dependent value class is a concrete class that the bean provider wishes to use internally within an entity bean, or one that is required to be exposed via the remote or local interface of the entity bean. A dependent value class can be the value of a CMP field but not a CMR field. A dependent value class is always manipulated using get()XXX/set()XXX methods by value and not by reference.

Until this point you have explored what CMP is and how field mappings and relationships are handled using the CMP fields and CMR fields, respectively. The question that now arises is to what extent CMP supports the development process of an entity bean. Tools provided by the EJB container generate the JDBC code needed to create a connection, prepare a statement, execute it, and obtain the results (if it is a query). For insert, update, delete, and the findByPrimaryKey() functionalities, it is the responsibility of the container provider's tools to generate the entire code including the SQL statements.

But an entity bean goes beyond just simple create, update, and delete functionality. The primary goal of an enterprise application is to retrieve data by performing business-relevant queries. These business-relevant queries cannot be automatically generated by the container provider's tools because the business queries are application-specific and differ from application to application.

Business specific queries need to be defined as findXXX() methods, which are also called finder methods. The queries for the finder methods need to be defined in the deployment descriptor file so that the container provider's tools can generate the appropriate code specific to the database. That is why the queries for the finder methods are written in the deployment descriptor file using SQL-like statements written in a pseudo-SQL language called EJB Query language (EJB QL), which will be discussed in the next section. The container provider's tools generate the actual SQL statements specific to the database along with the relevant JDBC code so that the bean provider is freed from this task.

Finally, take a quick look at the advantages and limitations of CMP. The primary advantage of CMP is the decoupling of the entity bean from the database that it accesses. This means that irrespective of the database being used, the entity bean would still be able to access data. This is because the EJB container is responsible for generating the database access functionality.

CMP does have its shortcomings. Because the EJB container generates data access routines, the EJB container provider must provide tools for mapping and code generation. To a certain extent this ties down the bean developer to a specific EJB container provider.