Head First EJB

Container-managed vs. bean-managed persistence

Container-managed persistence (CMP)

• Wimpy in EJB 1.1; greatly enhanced in EJB 2.0.

• The Bean Provider designs the entity bean class, choosing which of the bean’s fields are part of the bean’s persistent state. Persistent fields map to columns in one or more database tables.

• The Container keeps track of changes to the bean’s state and updates the real entity as needed. For example, if a client calls setLastName() on the bean, the Container knows that the real entity in the database has to be updated, so that if anyone else accesses the database for that entity (including non-EJB clients using some other means to get to the database), they’ll see the current state of the entity. The Container makes the decisions on how to keep the bean and the real entity synchronized based on the state of transactions. (More on that later).

• The Bean Provider writes EJB-QL to tell the Container how to do selects. EJB-QL is like a subset of SQL, but with some OO features. EJB-QL helps bridge the OO world of your bean to the relational world of your real entity.

• Using information in the deployment descriptor, the Container writes the actual implementation of the CMP bean, including implementing the finder and select methods, and all of the database access code. In other words, if you’re a Bean Provider writing a CMP bean, you do not look up a resource connection factory for the DataSource, get an SQL Connection, or write any JDBC code. Not only is the data access ...