La pregunta SCBCD del día: Stateful Session Beans

(Imagen: Henri Matisse - Mujer con sombrero)

A developer creates a stateful session bean that is used by many concurrent clients. The clients are written by other developement teams and it is assumed that these clients might not remove the bean when ending their session. The number of concurrent sessions will be greater than the defined bean cache size. The developer must consider that the state of the session bean can be influenced by either passivation or timeout. Which three actions should the developer take to make the bean behave correctly in passivation and timeout situations? (Choose three)

• Release references to resources ina a @Remove annotated method
• Re-establish references in an @Init annotated method
• Release references to resources in a @PreDestroy annotated method
• Release references to resources in a @PrePassivate annotated method
• Re-establish references to resources in a @PostActivate annotated method

La anotación @javax.ejb.Remove le indica al contenedor EJB que cuando el método anotado finalice, el cliente no necesita más de la sesión, y procede a removerla. LA pregunta indica que no es una garantía que los beans se remuevan de sesión, así que esta alterntiva queda descartada.

La anotación @javax.ejb.Init se usa por cuestiones de compatibilidad con los session beans de EJB 2. Los métodos anotados con @Init tienen un comportamiento similar al método create de un session bean de EJB 2. Nada que ver con la pregunta, así que la segunda no va.

Por otro lado, el contenedor puede desechar una instancia EJB cuando el bean expira (timeout). Cuando ocurra el timeout, el contenedor puede invocar al método anotado con @PreDestroy, por lo que sería un buen momento para liberar recursos. Cabe resaltar, que un bean Stateful no puede expirar mientras una transacción esté en proceso. Entonces, la tercera va.


Antes que un bean sea "pasivado" (passivated), se invoca al método del bean anotado como @PrePassivate. La instancia puede en este método cerrar recursos abiertos y colocar los campos no-serializables y no-transient a null (para evitar problemas al serializar, ya que los campos transient son ignorados). Se desea este comportamiento, por lo que la cuarta también va.

Después de la "pasivación", se procede a recuperar el estado conversacional del bean, y es ahí donde se invoca al método anotado como @PostActivate. Aquí, la instancia puede abrir recursos que no han sido "pasivados" e inicializar valores de sus campos transient. Bastante útil para nuetsros fines, por lo que la qunita va.

Concluyendo, tenemos la tercera, la cuarta y la quinta.

Pregunta tomada de ExamWorx