Stateless Session Bean Lifecycle
You already know that there are two different types of bean—stateful and stateless. You'll be learning about both types today, first, the simpler stateless bean. The Agency bean from the case study will be used for the example code.
Stateless beans hold no state for any particular client, but they do have a lifecycle—and thus different states—imposed on them by the EJB architecture. Specifically, these are the interactions between the bean and the container in which it has been deployed.
This is a recurrent theme throughout the EJB architecture, so it is important to fully understand it. The methods you define in your bean will be invoked either by its client or by the EJB container itself. Specifically, the methods invoked by the client will be those defined in the remote interface, whereas the methods invoked by the container are those defined by the javax.ejb.SessionBean interface. The bean must also provide methods that correspond to the create method of the bean's home interface.
Figure 5.2 shows the SessionBean interface and its super-interfaces.
Figure 5.2. The javax.ejb. SessionBean interface defines certain lifecycle methods that must be implemented by Session beans.
In the case study, the AgencyBean class indicates that it is a Session bean implementation by implementing this interface:
package agency;
import javax.ejb.*;
// some import statements omitted
public class AgencyBean implements SessionBean
{
// code omitted
}
The lifecycle for Session beans, as perceived by the Session bean and as likely to be enacted by the EJB container, is as shown in the UML state chart diagram in Figure 5.3.
Figure 5.3. Stateless Session beans have a lifecycle managed by the EJB container.
The lifecycle is as follows:
If the EJB container requires an instance of the stateless Session bean (for example, because the pool of instances is too small), it instantiates the bean and then calls the lifecycle method setSessionContext(). This provides the bean with a reference to a SessionContext object, providing access to its security and transaction context.
Immediately after the context has been set, the container will call ejbCreate(). This means that the bean is now ready to have methods invoked. Note that the ejbCreate() method is not part of the SessionBean interface, but nevertheless must be declared in the bean.
When a client invokes a business method, it is delegated by the bean's EJBObject proxy to the bean itself. During this time, the bean is temporarily bound to the client. When the method completes, the bean is available to be called again.
The binding of the bean to the client lasts only as long as the method takes to execute, so it will typically be just a few milliseconds. The EJB specification specifies this approach so that the bean developer does not need to worry about making the bean thread-safe.
To support the case where two (or more) clients need to invoke the service of some stateless Session bean at the same time, most EJB containers hold a pool of Session beans. In general, the pool will never be larger than the maximum number of concurrent clients. If a container decides that the pool is too large or that some Session bean instances are surplus, it will call the bean's ejbRemove() method.
Note
As you will see on Day 12, “Servlets,” servlets have similarities with stateless Session beans. However, in the servlet specification, they are defined to work in precisely the opposite way; by default, a servlet must be thread-safe, and there is only one instance of it.
If the client calls create() or remove(), the bean itself is not necessarily affected. However, the client's reference to the bean will be initialized (or destroyed). The client is not aware of the complexities of this lifecycle, so the client's perception of a stateless bean is somewhat simpler, as shown in Figure 5.4.
Figure 5.4. The client's perception of the bean's lifecycle is simple.
From the client's perspective, the bean is simply instantiated when the client calls create() on the bean's home interface, and is removed when the bean calls remove() on the bean itself.
Note
The EJB specification does not attempt to prescribe too closely the implementation of EJB containers, and correctly focuses instead on their specification. Unfortunately, it does not always identify the only realistic implementation.
For example, the EJB specification suggests that the EJB container is at liberty to adopt any appropriate pooling policy for Session beans. In Figure 5.3, you saw the state chart for a container using an eager instantiation policy, pre-instantiating beans before they are necessarily used. However, the fact that beans can throw CreateException exceptions from their ejbCreate() method seems to imply that only a lazy instantiation policy—instantiating beans only as they are required—could be used.
In fact, it is the case that some EJB containers do not maintain a pool of Session bean references and, instead, simply instantiate beans as required. In other words, the actual lifecycle for the bean matches that perceived by the client. While this might seem a wasteful approach, in fact it is not; modern JVMs are becoming so efficient that maintaining a pool of beans is more expensive than simply instantiating beans as needed.
Figures 5.3 and 5.4 show how the methods of the SessionBean interface are invoked through the bean's lifecycle. You will have noticed that the ejbActivate() and ejbPassivate() methods are not mentioned; this is because these methods are only called for stateful Session beans, a topic covered later today. However, given that these methods are in the SessionBean interface, they do require an implementation. For stateless Session beans, this implementation will be empty.
The implementation of the lifecycle methods is covered later today in the “Implementing a Stateless Session Bean” section.