SCBCD - Vida y milagros de un Stateful Session Bean

Una vez más le pedimos prestada una imagen a Mikalai Zaikin, para ver un poco del ciclo de vida de un Stateful Session Bean. Para empezar, los Stateful SB no son mantenidos en un pool a diferencia de los Stateless SB. El contenedor crea una instancia de un Stateful SB en el momento en que el cliente solicita una referencia a la interfaz de negocio del Bean. Es decir se mantiene una interfaz de Stateful SB por cada cliente que lo solicite. Pero vamos por partes:

• El cliente obtiene una referencia a la intefaz de negocio del bean (lookup JNDI o inyección de dependencia)
• Entonces, el contenedor invoca al constructor del bean, y ya tenemos nuestra instancia EJB
• Se da la inyección de dependencia, de ser el caso
• Y se invoca al método anotado como @PostConstruct, si es que hay alguno (siempre antes que se ejecute el primer método de negocio)
• El cliente invoca a un método de negocio, de la interfaz de negocio (redundante...no?)
• A través del contenedor, se invoca al método correspondiente en la instancia EJB creada, y se devuelve el resultado del método al cliente.
• Entonces, tenemos un cliente feliz
• Supongamos que nuestro cliente feliz se va a tomar un cafecito y deja la PC encendida
• El tiempo pasa... y no se detiene
• El contenedor alcance el límite de instancias de bean activas y, para mala suerte nuestra, decide que nuestro bean debe ser pasivado (passivated ... no sé si la traducción es correcta XD). Esto implica que nuestro bean será serializado y su estado será preservado y almacenado en memoria secundaria..como nuestro duro
  
• En su infinita sabiduría, el contenedor nos da la opción de liberar recursos antes de la pasivación mediante los métodos anotados como @PrePassivate
• Nuestra instancia EJB ahora esta "pasiva", y descansa plácidamente el el disco duro
• Se le acabó el café a nuestro cliente, y como no tiene plata para otro regresa al trabajo y vuelve a invocar a un método de negocio de nuestra instancia Stateful SB
• El contenedor saca a nuestra instancia de su letargo, la deserializa y vuelve a estar activa.
  
• Lógicamente, después de activar la instancia se invoca al método @PostActivate. Ahora sí se invoca el método de negocio de la instancia, y se le devuelve el resultado al cliente a través de la interfaz de negocio
• Nuevamente, nuestro cliente está muy feliz
  
• Llegaron las 6 pm, y se acabó el trabajo, por lo que nuestro cliente invoca a un método anotado como @Remove. Para el contenedor, esto indica que la instancia ya no es requerida, por lo que después de la ejecución del método se llama , si está presente , al método anotado como @PreDestroy, y se procede a remover la instancia EJB
• IMPORTANTE: Los métodos @PreDestroy se ejecutan después de completar cualquier método anotado con @Remove
  
• Y nuestro bean murió en el cumplimiento del deber.

PS: Dado que no se les encontró utilidad, no se definieron las anotaciones @PreConstruct (la instancia no existe), @PostDestroy (la instancia ya fue destruida) ni @PreActivate (la instancia está en el HD) ni @PostPassivate (ídem)