As you probably know, an important solution offered by EJB containers is the ability to manage concurrent requests and satisfy multiple clients while avoiding unpleasant issues. When the number of requests is too large and the available memory is insufficient, EJB containers try to use the hard disk to store the conversational state of each request that can’t be stored in memory. To accomplish this, the EJB container serializes the conversational state and stores it on the hard disk (known as the passivate process), and at the right moment it deserializes (restores) the conversational state and responds to the request (known as the activate process).

The limitation of this approach is that the container can’t serialize complex objects, such as sockets, database connections, JMS connections, and so on, because it can’t “capture” the state of such conversational states. This is why the EJB 3 provides the PrePassivate and PostActivate methods, annotated with @PrePassivate and @PostActivate, respectively. The first one, @PrePassivate, is called before storing the conversational state, which enables the developer to close any sockets and/or connections to databases and so on.

//called before storing conversational state@PrePassivate public void passivate(InvocationContext ic){   //close any socket, database connection etc.}

When the conversational state needs to be restored from hard disk, the @PostActivate method is called after the bean is restored (activated) to allow the developer to restore the potential connections, sockets and so on.

//called after the conversational state is restored (activated)@PostActivatepublic void activate(InvocationContext ic){   //reopen any socket, database connection etc.}