Sustitución por migración tras error de beans de sesión con estado para el contenedor de EJB

Puede utilizar WebSphere Application Server para crear aplicaciones que utilicen beans de sesión con estado que no estén limitados por anomalías inesperadas del servidor. El producto utiliza las funciones del Servicio de duplicación de datos (DRS) y Gestión de cargas de trabajo (WLM), de forma que puede habilitar la migración tras error de beans de sesión con estado.

Como es posible que no desee habilitar la sustitución por anomalía para cada bean de sesión con estado que esté instalado en el contenedor de EJB (Enterprise JavaBeans ), puede alterar temporalmente los valores del contenedor de EJB para el nivel de aplicación o módulo EJB. Puede habilitar o inhabilitar la migración tras error en cada uno de esos niveles. Por ejemplo, tenga en cuenta las situaciones siguientes:
  • Desea habilitar la migración tras error para todas las aplicaciones excepto una. Para ello, debe habilitar la migración tras error al nivel de contenedor de EJB y alterar temporalmente los valores a nivel de aplicación para inhabilitar la migración tras error en esa única aplicación.
  • Desea habilitar la migración tras error para una sola aplicación instalada. Para ello, debe inhabilitar la migración tras error al nivel de contenedor de EJB y alterar temporalmente los valores a nivel de aplicación para habilitar la migración tras error en esa única aplicación.
  • Desea habilitar la migración tras error para todas las aplicaciones excepto en un módulo de una aplicación. Para ello, debe habilitar la migración tras error al nivel de contenedor de EJB, a continuación, alterar temporalmente los valores a nivel de aplicación del módulo para inhabilitar la migración tras error en ese módulo.
  • Desea habilitar la migración tras error para un solo módulo EJB instalado. Para ello, debe inhabilitar la migración tras error al nivel de contenedor de EJB y alterar temporalmente los valores a nivel de módulo EJB para habilitar la migración tras error en ese módulo EJB.
Para obtener más información sobre la habilitación de la migración tras error de beans de sesión con estado desde la consola administrativa, consulte los temas siguientes:
  • Habilitación o inhabilitación de la migración tras error del bean de sesión con estado con el panel de contenedor de EJB
  • Habilitación o inhabilitación de la migración tras error del bean de sesión con estado con el panel de aplicaciones empresariales
  • Habilitación o inhabilitación de la migración tras error del bean de sesión con estado con el panel de módulos EJB

Política de activación de beans de sesión con estado con la migración tras error habilitada

Puede especificar una política de activación para beans de sesión con estado durante el ensamblaje de aplicaciones. Es importante considerar que el único momento en que el contenedor de EJB se prepara para la migración tras error, replicando los datos del bean de sesión con estado utilizando DRS, es cuando se desactiva el bean de sesión con estado. Si configura el bean con una política de activación activo una vez, que es el valor predeterminado, el bean no se desactiva con rapidez suficiente para resultar útil para la migración tras error del bean de sesión con estado. Por lo tanto, cuando se habilita la migración tras error, el contenedor EJB ignora la política de activación configurada para el bean y utiliza automáticamente la política de activación activar en el límite de transacción. Esta acción garantiza que el bean se desactiva y los datos se duplican siempre que está incluido en una transacción que finalice.

Avoid trouble Avoid trouble: Cuando a DRS se le otorgan datos para replicar, DRS replica los datos para N-1 servidores de aplicaciones, siendo N el número de réplicas disponibles. Si el servidor de creación y todos los servidores que retienen copias de seguridad de los datos fallan o se detienen, los datos de réplica se pierden a menos que el consumidor de DRS vuelva a replicarlos.gotcha

Utilización del bean de sesión con estado de las unidades de trabajo gestionadas por contenedor o de las unidades de trabajo gestionadas por bean con la migración tras error habilitada

Las unidades de trabajo relevantes en este caso son las transacciones y las sesiones de actividad. El producto soporta la migración tras error del bean de sesión con estado para las transacciones gestionadas por contenedor (CMT), las transacciones gestionadas por bean (BMT), las sesiones de actividad gestionadas por contenedor (CMAS) y las sesiones de actividad gestionadas por bean (BMAS). Sin embargo, en los casos gestionados por contenedor, la preparación para la migración tras error sólo se da si envía una solicitud de invocación de método de un enterprise bean tiene como resultado la falta de conexión con el servidor. Asimismo, si el servidor falla después de recibir y reconocer una solicitud, no se producirá la migración tras error. Cuando se produce una anomalía en medio de una solicitud o una unidad de trabajo, WLM no puede realizar una migración tras error de forma segura a otro servidor sin que la aplicación ejecute algún tipo de código compensación. Cuando esto ocurre, la aplicación recibe una excepción CORBA (Common Object Request Broker Architecture) y un código menor que especifica que no debe ocurrir una migración tras error transparente porque la anomalía se ha producido durante la ejecución de una unidad de trabajo. Debe escribir la aplicación para comprobar la excepción CORBA y el código menor, y compensar la anomalía. Una vez ejecutado el código de compensación, la aplicación puede reintentar las solicitudes y, si existe una vía de acceso a un servidor de copia de seguridad, WLM direcciona la nueva solicitud a un nuevo servidor principal para el bean de sesión con estado.

[AIX Solaris HP-UX Linux Windows][IBM i]Para obtener más información, consulte el tema Códigos menores de CORBA.

Para obtener más información, consulte el tema Gestión de carga de trabajo para todas las plataformas excepto z/OS.

Lo mismo ocurre para las unidades de trabajo gestionadas por bean como transacciones o sesiones de actividad. No obstante, el trabajo gestionado por bean presenta una nueva posibilidad que debe considerarse.

Para las unidades de trabajo gestionadas por bean, el proceso de migración tras error no siempre puede detectar que una BMT o BMAS iniciada por un método de bean de sesión con estado no se ha completado. Así, es posible que la migración tras error para un nuevo servidor se produzca a pesar de que la unidad de trabajo haya fallado en el medio de una sesión o una transacción. Como la unidad de trabajo se retrotrae de forma implícita, WLM se comporta como si fuera seguro realizar la migración tras error a otro servidor, cuando de hecho se necesitará algún tipo de código de compensación. Cuando sucede esto, el contenedor de EJB detecta este comportamiento en el nuevo servidor e inicia una excepción. Esta excepción se produce en el escenario siguiente:
  1. Un método de un bean de sesión con estado que utiliza la sesión de actividad o la transacción gestionada por bean llama al método begin en una UserTransaction que ha obtenido del objeto SessionContext. El método realiza algunas tareas en la unidad de trabajo iniciada, pero no completa la transacción o la sesión antes de regresar al interlocutor del método.
  2. Una vez que se ha iniciado la invocación del método, el contenedor de EJB suspende el trabajo que el método había iniciado. Esta es la acción que necesita la especificación de Enterprise JavaBeans para unidades de trabajo gestionadas por bean cuando el bean es un bean de sesión con estado.
  3. El cliente inicia otros métodos en el bean de sesión con estado. Cada invocación hace que el contenedor de EJB reanude la sesión de actividad o de transacción suspendida, asigne la invocación del método, y vuelva a suspender el trabajo antes de volver al interlocutor.
  4. El cliente llama a un método en el bean de sesión con estado que completa la transacción o la sesión iniciada en el paso 1.

En este escenario se ilustra una unidad de trabajo gestionada por bean que permanece en memoria. La sesión de actividad o de transacción permanece en memoria durante un tiempo superior al de un solo método de bean de sesión con estado. Si una aplicación utiliza una BMT o BMAS con permanencia en memoria, y el servidor sufre una anomalía después de que se complete una unidad de trabajo con permanencia en memoria y antes de que se inicie otra unidad de trabajo con permanencia en memoria, la migración tras error es satisfactoria. Sin embargo, si el servidor sufre la anomalía antes de que se complete una sesión de actividad o de transacción con permanencia en memoria, la migración tras error no es satisfactoria. Por el contrario, cuando el proceso de migración tras error direcciona la solicitud del bean de sesión con estado a un nuevo servidor, el contenedor EJB detecta que la migración tras error se ha producido durante una sesión de actividad o de transacción con permanencia en memoria activa. En ese momento, el contenedor EJB inicia una excepción.

Este proceso indica que la migración tras error tanto para unidades de trabajo gestionadas por contenedor como para unidades de trabajo gestionadas por bean no es satisfactoria si la sesión de actividad o de transacción sigue activa. La única diferencia es que se produce una excepción para las unidades de trabajo gestionadas por bean.

Consideraciones sobre el diseño de aplicaciones

Cuando diseñe aplicaciones que utilicen procesos de migración tras error de beans de sesión con estado, considere la información siguiente:
  • Para evitar la excepción descrita en la sección anterior, es recomendable que escriba su aplicación para que configure beans de sesión con estado que utilicen transacciones gestionadas por contenedor (CMT) en lugar de transacciones gestionadas por bean (BMT).
  • Si desea una migración tras error y la aplicación crea una sesión HTTP o un bean de sesión con estado que almacene una referencia a otro bean de sesión con estado, el administrador debe garantizar que el bean de sesión con estado y la sesión HTTP estén configurados para utilizar el mismo dominio de réplica DRS (Servicio de réplica de datos).
  • No utilice una referencia local y una remota al mismo bean de sesión con estado.

    Normalmente, una instancia de bean de sesión con estado con una clave primaria determinada sólo puede existir en un único servidor en un momento concreto del tiempo. La migración tras error puede causar que el bean se traslade de un servidor a otro, pero nunca existe en más de un servidor al mismo tiempo. Sin embargo, ciertos escenarios menos frecuentes pueden dar como resultado que la misma instancia de bean (la misma clave principal) se dé en más de un servidor a la vez. Cuando se produce este caso, cada copia del bean no conoce la existencia de los otros y no se produce ninguna sincronización entre las dos instancias para asegurarse de que contienen los mismos datos. De este modo, la aplicación recibe resultados impredecibles.

    Atención: Para evitar esta situación, no debe olvidar que si está activada la migración tras error, la aplicación no debe obtener nunca una referencia local (EJBLocalObject) y otra remota (EJBObject) de la misma instancia de bean de sesión con estado.
  • Evite el uso de métodos asíncronos remotos en beans de sesión con estado.

    Cuando se invoca un método asíncrono, dicha solicitud se pone en cola en el servidor remoto, y se devuelve un objeto Future al cliente. Puesto que la petición de método sólo se pone en cola en el servidor con la instancia del bean de sesión con estado, el objeto futuro se enlaza a dicho servidor y no realiza la sustitución por anomalía. Si necesita utilizar métodos remotos asíncronos para beans de sesión con estado, escriba la aplicación para que detecte cuando una llamada al objeto futuro falla y realizar una llamada síncrona al bean de sesión con estado para determinar si la transacción que se inició mediante el método asíncrono se ha completado correctamente.

  • Evite hacer referencia a temporizadores EJB no persistentes en la instancia de bean de sesión con estado cuando la sustitución por anomalía esté habilitada.

    Si un bean de sesión con estado incluye un descriptor de contexto de una instancia de temporizador no persistente creada automáticamente o mediante programación, el descriptor de contexto no es válido después de que se realice una sustitución por anomalía del bean de sesión con estado y se produce la excepción javax.ejb.NoSuchObjectLocalException cuando se utiliza este descriptor de contexto. Si la aplicación debe hacer referencia a temporizadores no persistentes en beans de sesión con estado, escriba la aplicación de modo que tenga en cuenta el descriptor de contexto no válido.

    Atención: Los descriptores de contexto que apuntan a los temporizadores persistentes de beans de sesión con estado que se hayan creado automáticamente o de forma programada, se migrarán tras error, y se podrán utilizar después de que se haya producido una migración tras error de beans de sesión con estado.
[z/OS]

Sólo para los usuarios de z/OS

La sustitución por anomalía de beans de sesión con estado en WebSphere Application Server, Network Deployment para z/OS es ligeramente diferente de la del producto WebSphere Application Server, Network Deployment. Además de la solución de sustitución por anomalía que se describe aquí, los usuarios de z/OS también pueden habilitar la sustitución por anomalía entre los servants de un servidor no gestionado. Para obtener más información, consulte los temas:
  • Varios sirvientes
  • Configuración de reinicio y recuperación por igual
  • Clústeres en los que se pueden desplegar los beans de sesión con estado

Como el producto z/OS tiene una región de control y regiones de servant y el producto WebSphere Application Server, Network Deployment no, existe un caso de sustitución por anomalía que es exclusivo de z/OS, que es la sustitución por anomalía de una región de servant a otra región de servant (la pérdida de un servant sin la pérdida del controlador).

Si utiliza la técnica basada en HFS en z/OS, continúe con esa dicha técnica.

En un servidor z/OS no gestionado, se puede habilitar la migración tras error de beans de sesión con estado entre sirvientes. La migración tras error sólo se produce entre los sirvientes de un servidor no gestionado. Si un servidor z/OS no gestionado sólo tiene un sirviente, la habilitación de la migración tras error no tiene ningún efecto. Un gestor z/OS no gestionado que tenga habilitada la migración tras error no pasa a otro servidor z/OS no gestionado. Para habilitar la migración tras error en un servidor no gestionado, consulte el tema sobre cómo habilitar la migración tras error de sirvientes en un servidor no gestionado.


Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cejb_sfsbf
File name: cejb_sfsbf.html