2011-11-19 9 views
7

Si el bean de sesión con estado se va a pasivar, su estado se escribe en el disco duro y luego la instancia de bean se liberará para servir a otra solicitud (al menos esto es lo que yo entiendo). Cuando el mismo cliente está activo nuevamente, la instancia de bean leerá el estado del disco duro para recuperar el estado. Pero, ¿cómo sabe la instancia de bean para qué cliente qué archivo debe leer para mantener el estado?¿Cómo se recupera un bean de sesión con estado cuando el cliente regresa?

Soy muy nuevo en J2EE, así que, por favor, perdónenme si les hago una pregunta muy ingenua. Si necesito saber algún otro tema para comprender esto, por favor, apúnteme en la dirección correcta.

Respuesta

13

Lo mejor es visualizar un Bean de sesión Stateful (SfSB) como muy cerca de una instancia de una clase Java normal. Mira hacia arriba (o inyecta) una instancia de un SfSB, y el contenedor creará uno para usted y devolverá la instancia. Luego trabajas con esa instancia como lo harías con cualquier otra instancia de Java.

Eso significa que se puede almacenar en la instancia a una sesión, serializar en el disco, etc.

El detalle es que la instancia que está trabajando es en realidad un proxy para el actual, que subyace ejemplo SfSB. No es el propio SfSB en sí.

Cuando realiza una llamada en su proxy local al bean, es el trabajo de los contenedores para manifestar ese bean en la memoria por usted. La pasivación y activación del bean se realiza detrás de escena para usted (aunque puede acceder al proceso a través del ciclo de vida de los beans).

Cualquier información que el contenedor necesita para encontrar el SfSB pasivado se almacena en el proxy con el que está trabajando, pero esto es opaco para usted. No necesitas preocuparte por eso.

Por lo tanto, en un escenario típico basado en web, el ciclo de vida sería que obtienes tu instancia de bean, la almacena en una sesión web y luego simplemente la utilizas como siempre. Si el contenedor decide que debe pasivar su grano para hacer espacio o lo que sea, lo pasivará automáticamente. Cuando su usuario regrese, su aplicación extrae la instancia de la sesión web y realiza sus llamadas. En ese momento, si el frijol es pasivado, el contenedor activará el frijol automáticamente, nuevamente. Todo este mecanismo depende del contenedor, pero es transparente para usted. Lo importante para que recuerde es que debe aferrarse a SfSB que obtiene del contenedor, como lo haría con cualquier objeto de Java.

La advertencia final es que si permite que un SfSB sea pasivado durante demasiado tiempo, el contenedor lo eliminará automáticamente por usted.

+0

Gracias Will por la explicación. Pero, ¿es posible que un usuario regrese después de que se borre SfSB? Y si es posible, ¿qué sucederá en ese escenario? – Bhushan

+2

Sí, es absolutamente posible. Si sucede, obtendrá una excepción cuando intente acceder al SfSB (la excepción exacta, no podría decir). El tiempo de espera de un SfSB es configurable (a través de una anotación en EJB 3.1, o mediante un mecanismo específico de contenedor en EJB 3), por lo que el objetivo sería atar la duración del tiempo de espera a la esperanza de vida esperada del estado. Dicho esto, no les daría un alcance ilimitado. Además, es bastante probable que el SfSB no sobreviva al redespliegue de la aplicación. Reinicio del servidor, sí, pero no redistribución. –

Cuestiones relacionadas