CMP Entity Bean Lifecycle
The lifecycle for CMP Entity beans is substantially the same as BMP Entity beans, reflected in an almost identical diagram (see Figure 7.3).
Figure 7.3. The javax.ejb.EntityBean lifecycle for CMP Entity beans.
This diagram differs from the 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. There will be a finder method in the bean's local-home interface, but not necessarily an equivalent ejbFindXxx() method in the bean itself (and certainly not in the code written by the bean provider).
Note
Where the implementation of the finder methods is will depend on the EJB container. It does seem likely that many vendors will choose to place the finder logic in the bean's concrete implementation. An advantage of this approach (for the EJB container vendor) is that the rest of the EJB container need not differentiate between BMP and CMP Entity beans.
Yesterday, you saw the responsibilities of the bean provider for each of these lifecycle methods for the Job bean when implemented using BMP. The implementation is somewhat simpler when using CMP.
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 DataSource should not be 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 does not need to do this, but does still need to set the bean's fields to the parameters passed in. This can include generating a unique primary key value.
The BMP version of ejbRemove() was responsible for physically removing the bean's state from the data store. The CMP version does not need to do this (and later on, you'll see that this method actually has a null implementation).
Nevertheless, sometimes there may be occasions when work needs to be done in the ejbRemove() method. For example, you could imagine an Entity bean that has some subscribers interested in observing its changing state. One such Entity bean might be a headline news item publicized from Reuters. When this Entity bean is finally removed, it would notify those subscribers of the event.
On a more mundane level, the bean might want to prevent the delete from occurring if, for example, some referential integrity constraint would be violated by the bean being removed. In such cases, you need to know that the ejbRemove() is called before the container actually removes the data.
Next are the ejbLoad() and ejbStore() methods. Under BMP, these methods for the Job bean were substantial, because they had to read/write the bean's state to both the Job and JobSkill tables. Under CMP, unless there is any derived data to be maintained, these methods could well have an empty implementation.
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.
If you've been mentally (or manually) comparing this section with the previous section yesterday, you'll note that yesterday there was discussion on the finder methods. There is no such discussion here because the finder methods will be generated automatically. However, as the bean provider, you will need to indicate to the container the semantics of the finder queries. To do that, you must be familiar with EJB QL. But to understand EJB QL queries of any complexity, you need first to understand container-managed relationships. CMR is discussed in the next section, followed then by EJB QL.