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.

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. The setEntityContext() should be used to initialize any state (such as instance variables) required by the Entity bean.

• Pooled instances can service finder methods to locate data within a persistent data store. 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() in order to invoke a business method.

  Alternatively, the ejbCreate() method can be used to create and initialize a new Entity bean.

• When the bean has been associated with its proxy, business methods can be invoked on it. Before the business method is invoked, 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 will typically simply sever the link from the EJBLocalObject proxy to the bean.

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

• Finally, the EJB container can reduce the size of its pool by calling unsetEntityContext() on any Entity bean. This bean will then be released for garbage collection.

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

As shown in Figure 6.5 there are two methods called during the creation of a bean. The ejb Create() 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.

Figure 6.6. Both the ejbCreate() and ejbPostCreate() lifecycle methods are called when an Entity bean is created.

[View full size image]

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 database, this will most likely be in the form of a SQL INSERT statement or statements.

• Save the supplied arguments and its primary key to member variables.

• Return the primary key.

The ejbPostCreate()method allows for additional processing of a new Entity bean after the proxy object has been created but is rarely used. However, an ejbPostCreate() method must be defined for each ejbCreate() method; the parameter list of the ejbCreate() and associated ejbPostCreate() methods must be identical.

The ejbRemove() method is the opposite of the ejbCreate() method; it removes a bean's data from the persistent data store (typically by issuing a SQL DELETE operation). 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 methods of the Entity bean lifecycle are ejbLoad() and ejbStore(). 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 typically using a SQL SELECT statement). The ejbStore() is called after the business method completes (so that the bean's state is reflected in the persistent data store typically using a SQL UPDATE statement). Figure 6.7 shows this as a UML sequence diagram.

Figure 6.7. The ejbLoad() and ejbStore() methods keep the bean in sync with the persistent data store.

[View full size image]

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

These lifecycle methods allow new beans (and data in the persistent data store) to be created, and existing beans to be removed or updated. But what about actually finding beans that already exist? In other words, in database terms, you have seen the lifecycle methods that correspond to SQL INSERT, DELETE, and UPDATE statements, but what of the SQL SELECT statement?

Existing data is retrieved by finder methods. The EJB specification requires at least one finder method, whose name must be ejbFindByPrimaryKey(), and allows other finder methods to be defined by the developer. All finder method names must begin with ejbFind. These methods have corresponding find methods in the home interface.

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. This has implications for the bean lifecycle. Put simply, an ejbFind() method may be called before any other method except setEntityContext(). If an entity bean maintains a connection to a data source, this connection must be initialized in the setEntityContext() method.

Learning the 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.