CMP Entity Bean Lifecycle

The actual lifecycle for CMP Entity beans is substantially the same as BMP Entity beans. Compare Figure 7.2 with the lifecycle for BMP Entity beans shown in the previous chapter.

The CMP lifecycle differs from the BMP lifecycle you saw yesterday in that there are no ejbFindXxx() methods for pooled beans. This is not to say that pooled CMP Entity beans do not perform finder methods; they do. However, the EJB container generates the actual code that performs this from EJB QL information provided in the deployment descriptor. There must be a finder method in the bean's local-home interface, but no equivalent ejbFindXxx() method in the bean itself.

As for BMP Entity beans, the setEntityContext() and unsetEntityContext() methods must be implemented to look up any required resources (although the resources are likely to be different than those needed for BMP; in particular, the JDBC data source is not needed).

Under BMP, the ejbCreate() method was responsible for persisting the newly created bean's state to the persistent data store. Under CMP, the ejbCreate() method no longer has to do this, but does still need to set the bean's attributes to the parameters passed in. This can include generating a unique primary key value.

Similarly, the BMP version of ejbRemove() was responsible for physically removing the bean's state from the data store, again the CMP version does not need to do this. However, there may be occasions when work does need to be done in the ejbRemove() method. For example, the bean might want to prevent the delete from occurring if, for example, removing the bean would violate some referential integrity constraint. In such cases, you need to know that the ejbRemove() is called before the container actually removes the data and can throw an EJBException to abort the actual database delete.

Next are the ejbLoad() and ejbStore() methods. As you saw yesterday when using BMP, these methods for the Job bean were substantial. This is because they had to maintain the bean's state accessing both the Job and JobSkill database tables. Under CMP these methods normally have an empty implementation, as all the interactions with the persistent data store are done by the EJB container.

However, it may be that the physical schema of the persistent data store (especially if that persistent data store is a relational database) does not correspond exactly with the logical schema of the Entity bean.

For example, in the Agency case study, the Applicant table defines two columns—address1 and address2. However, at least conceptually, the Applicant Entity bean has a vector field of address, of type String[]; there could be many lines in the address (and it's just that the physical schema of the persistent data store constrains the size of this vector to 2).

Because the ejbLoad() method is called after the EJB container has loaded the data, it may renormalize it. In other words, the data in the two CMP fields of address1 and address2 can be converted into the String[] address field. The bean's clients' view (as presented by the methods of the local interface) is that the address field is a vector.

Conversely, the ejbStore() method, called just before the EJB container updates the data, can denormalize the data. In other words, the data in the address vector field can be “posted” back to the address1 and address2 CMP fields.

The ejbActivate() and ejbPassivate() methods for a CMP Entity bean are pretty much identical to their implementations for a BMP Entity bean; after all, these methods have nothing to do with the persistent data store.

You have now seen the Java code for a CMP Entity bean, but before you can look at writing the EJB QL code for the finder methods you need to understand container-managed relationships. CMR is discussed in the next section.