EJB 3 Lifecycle Callback Methods

Session beans have a lifecycle. This means that beans go through a predefined set of state transitions.
The container manages almost every aspect of session beans, from the creation, through to the injection of resources as you saw on my last post with the @Resource annotation, to the distruction of the bean.
Managing those actions allows the container to provide the abstractions that are some of the real value of using EJBs, like DI, transaction management, AOP, security, etc.
The lifecycle of a session bean has at least 2 events: the creation and the destruction. Stateful session beans have other 2 phases: activation and passivation.
The first phase of a bean lifecycle is the bean creation; it happens when a client receives an instance of a bean. During this phase a new instance of a bean is created an, it is initialized by calling its constructor and, if any resource is required, those will be injected in the newly created instance.
The last phase of a bean lifecycle is the bean destruction: it occurs when the container determines that the instance is no longer needed and all the resources previously injected in the bean will be released.

Lifecycle callbacks are bean methods, not exposed by the business interface, that the container uses to notify the bean about a lifecycle transition or an event. These methods could be used to perform business logic or to initialize or cleanup the injected resources.

 The callback methods common to all session beans are annotated with metadata annotations @PostConstruct and @PreDestroy.
The method annotated with the @PostConstruct annotation will be called by the container just after the creation of the bean, while the callback method annotated with the @PreDestroy annotation will be called by the container just before the destruction of the bean.
In the following picture you can see an example of these 2 methods in which I initialized and cleanup the resources I used on my LoginBean: the connection to the dataSource.

As you can see, the bean on the previous picture is a stateless session bean so I only have the callback methods inherent to the construction and the destruction of the bean, annotated as @PostConstruct and @PreDestroy. The only think I did in these methods is open the connection to the dataSource in the initialize method, and close the same connection to the dataSource in the cleanUp method that is called before the bean destruction by the container.

The stateful session bean, could have other two callback methods because of the other other two phases of its lifecycle. As you know the stateful session bean can maintain state to serve the same client during his session. If the client is inactive for a while, the stateful session bean is passivated, and when the client is back active the bean is re-activated. During these phases the container could call the other two callback methods to manage the resources of the bean or doing any other business logic. The methods associated with these two phases are annotated with the metadata annotations @PostActivate that will be called after the activation of the bean, and the @PrePassivate metadata annotation.

In the previous picture I have a stateful session bean. I used the same method for the @PostConstruct and @PostActivate lifecycle phase because I do need the same resources in both the phases: I open the connection to the dataSource. I also have only one method for @PreDestroy and @PrePassivate phases and in this method I close the connection to the dataSource.
If I want to do any other thing before or after one of the lifecycle phases I could create another method just for that phase.
Thats all for the callback methods, in the next method I will talk about the stateful session beans.