Life cycle events
Another very powerful use of annotations is to mark callback methods for session bean life cycle events.
EJB 2.1 and prior releases required implementation of several life cycle methods, such as ejbPassivate, ejbActivate, ejbLoad, and ejbStore, for every EJB, even if you do not need these methods.
Because we use POJOs in EJB 3.0, the implementation of these life cycle methods has been made optional. Only if you implement any callback method in the EJB, the container will invoke that specific method.
The life cycle of a session bean can be categorized into several phases or events. The most obvious two events of a bean life cycle are creation and destruction for stateless session beans.
After the container creates an instance of a session bean, the container performs any dependency injection (described in the section that follows), and then invokes the method annotated with @PostConstruct (if there is one).
The client obtains a reference to a session bean and invokes a business method.
|
Note: The actual life cycle of a stateless session bean is independent of when a client obtains a reference to it. For example, the container might hand out a reference to the client, but not create the bean instance until some later time, for example, when a method is actually invoked on the reference. Or, the container might create a number of instances at startup time, and match them up with references at a later time. |
At the end of the life cycle, the EJB container calls the method annotated with @PreDestroy (if there is one). The bean instance is ready for garbage collection.
A stateless session bean with the two callback methods is shown here:
@Stateless
public class MyStatelessBean implements MyBusinessLogic {
// .. bean business method
@PostConstruct
public void initialize() {
// initialize the resources uses by the bean
}
@PreDestroy
public void cleanup() {
// deallocates the resources uses by the bean
}
}
All stateless and stateful EJBs go through these two phases.
In addition, stateful session beans go through the passivation/activation cycle. Because an instance of a stateful bean is bound to a specific client (and therefore it cannot be reused among different requests), and the EJB container must manage the amount of physical available resources, the EJB container might decide to deactivate, or passivate, the bean by moving it from memory to secondary storage.
In correspondence with this more complex life cycle, we have further callback methods, specific to stateful session beans:
| The EJB container invokes the method annotated with @PrePassivate, immediately before passivating it. |
|
| If a client invokes a business method on the bean while it is in the passive stage, the EJB container activates the bean by calling the method annotated with @PostActivate, if any, and then moves it to the ready stage. |
|
| At the end of the life cycle, the client explicitly invokes a method annotated with @Remove, and the EJB container, in turn, calls the callback method annotated @PreDestroy. Developers can explicitly invoke only the life cycle method annotated with @Remove; the other methods are invoked automatically by the EJB container. |
|
Note: Because a stateful bean is bound to a particular client, it is best practice to correctly design stateful session beans to minimize their footprint inside the EJB container, and to correctly un-allocate it at the end of its life cycle, by invoking the method annotated with @Remove. Stateful session beans have a time-out value. If the stateful session bean has not been used in the time-out period, it is marked inactive and is eligible for automatic deletion by the EJB container. Of course, it is still best practice for applications to remove the bean when the client is through with it, rather than relying on the time-out mechanism to do this. |
|
ibm.com/redbooks |