BMP Entity Bean Lifecycle

The lifecycle of both BMP and CMP Entity beans is dictated by the EntityBean interface that the bean must implement. This is shown in Figure 6.4.

However, although the method names are the same, the obligations of BMP versus CMP Entity beans for each of those methods are different. This section discusses just those lifecycle methods for BMP Entity beans. The Job Entity bean from the case study will predominantly be used for example code.

To start with, the Entity bean must implement the javax.ejb.EntityBean interface, as demonstrated with the JobBean class:

package data;

// imports omitted
import javax.ejb.*;

public class JobBean implements EntityBean
{
    // implementation omitted
}

The lifecycle as perceived by the Entity bean and as managed by the container is as shown in Figure 6.5.

The lifecycle is as follows:

• If the EJB container requires an instance of an Entity bean (for example, if the pool is too small), it will instantiate the bean instance and call its setEntityContext() method.

• Pooled instances can service finder methods to locate data within the persistent data store that represents existing beans. More on these finder methods shortly.

• A bean can be associated with an EJBLocalObject proxy (or EJBObject proxy if the remote interface is in use) in one of two ways.

  First, it can be activated by the container via ejbActivate(). The proxy for the bean exists but has no associated bean. This could occur if the bean had previously been passivated and a business method has now been invoked on the proxy. It could also occur if the bean's proxy was just returned as the result of a finder method.

  Alternatively, the client may be requesting to create an Entity bean via ejbCreate() and then ejbPostCreate(). This usually means that the corresponding data has been inserted into the persistent data store.

• When the bean has been associated with its proxy, business methods can be invoked on it. Before the business method is delegated by the proxy to the bean, the ejbLoad() lifecycle method will be called, indicating that the bean should re-load its state from the persistent data store. Immediately after the business method has completed, the ejbStore() method is called, indicating that the bean should update the persistent data store with any change in its state.

• Beans can return to the pooled state in one of two ways.

  First, they can be passivated via ejbPassivate(). There is usually little to be done in this method, because the bean's state will already have been saved to the persistent data store during the earlier ejbStore() method. So passivation simply means that the link from the EJBLocalObject proxy to the bean has been severed.

  Alternatively, the client may be requesting to remove the create bean via ejbRemove(). This usually means that the corresponding data in the persistent data store has been deleted.

• Finally, if the EJB container wants, it can reduce the size of its pool by first calling unsetEntityContext().

Unlike Session beans, there is no binding of the Entity beans to a specific client; the bean can be shared by all clients.

As Figure 6.5 indicated, there are two methods called during the creation of a bean. The ejbCreate() method is called prior to the EJBLocalObject proxy being made available, then the ejbPostCreate() method is called after the proxy is available. This is shown in the sequence diagram in Figure 6.6.

Under BMP, the bean has several tasks to perform when its ejbCreate() method is called. It should:

• Calculate the value of its primary key (if not passed in as an argument).

• Persist itself to a data store. For a RDBMS, this will most likely be in the form of an SQL INSERT statement or statements.

• Save the supplied arguments and its primary key to fields.

• Return the primary key.

As Figure 6.6 shows, the returned primary key is passed to the bean's proxy, and the proxy continues to hold that primary key, even if the bean is subsequently passivated. The proxy for the bean is also associated with the context object of the bean.

The ejbRemove() method is the opposite of the ejbCreate() method; it removes a bean's data from the persistent data store. The implementation of ejbCreate() and ejbRemove() is given in the “Implementing javax.ejb.EntityBean” section later today.

That takes care of creating and removing beans, but what about when a bean is queried or updated? The most significant of the Entity bean lifecycle methods are the ejbLoad() and ejbStore()methods. Together, these methods ensure that the Entity bean is kept in sync with the persistent data store. The ejbLoad() method is called immediately prior to any business method (so that a query accesses the most up-to-date data). The ejbStore() is called after the business method completes (so that if the method updated the bean's state, this is reflected in the persistent data store). Figure 6.7 shows this as a UML sequence diagram.

Again, the actual implementation for these methods is given in the “Implementing javax.ejb.EntityBean” section later today.

As you will recall, Session beans have ejbActivate() and ejbPassivate() methods, and so do Entity beans. If the EJB container wants to reduce the number of bean instances, it can passivate the bean. This is only ever done after an ejbStore(), so the data represented by the bean is not lost. Also, the proxy for the bean continues to hold the bean's primary key, meaning that if the client interacts with the bean (through the proxy) in the future, the appropriate data can be loaded from the persistent data store. Generally, then, there is little or nothing to be done when an Entity bean is passivated or activated.

These lifecycle methods allow new beans (and data in the persistent data store) to be created or removed and updating existing beans, but what about actually finding beans that already exist? In other words, in JDBC terms, you have seen the lifecycle methods that correspond to SQL INSERT, DELETE, and UPDATE statements, but what of an SQL SELECT statement? Well, this is accomplished by the finder methods. The EJB specification requires at least one finder method, whose name must be ejbFindByPrimaryKey(), and allows other finder methods, whose names must begin ejbFind. These methods have corresponding methods in the local-home interface, so you'll be learning about them shortly as part of specifying and implementing the bean.

One obvious question arises, “When the client invokes the finder method on the home interface, which bean actually performs the ejbFindXxx() method?” The answer is perhaps a little unexpected; any unused (that is, pooled) bean will be used by the EJB container.

Learning all these lifecycle methods for both Entity and Session beans can be somewhat overwhelming at first, made all the more complicated because some method names appear for both bean types but imply different responsibilities. To clarify matters, Table 6.1 compares the two sets of lifecycle methods and identifies those responsibilities.