Consideraciones sobre el entorno de clúster para el servicio de temporizador
En un entorno de un servidor, no hay duda sobre qué instancia de servidor debe invocar el método de tiempo de espera del bean en un bean determinado. En un entorno de clúster con varios servidores existen otras consideraciones que controlan el comportamiento.
WebSphere Application Server implementa el servicio de temporizador EJB (Enterprise JavaBeans). En función de las necesidades de la empresa, puede utilizar temporizadores persistentes o no persistentes. Los temporizadores persistentes resultan de utilidad cuando se crea un temporizador para sucesos basados en tiempo que requieren la existencia del temporizador más allá del ciclo de vida del servidor para sobrevivir a las operaciones de conclusión y reinicio del servidor. Los temporizadores persistentes iniciados con anterioridad se inician automáticamente cuando el servidor se inicia y requieren una instancia de base de datos. Los temporizadores no persistentes no utilizan un almacén de datos y se cancelan cuando el servidor de aplicaciones se detiene o no puede mantenerse en estado activo. Los temporizadores no persistentes sólo existen en el servidor en el que se han creado. En un entorno en clúster, si la aplicación EJB crea automáticamente un temporizador no persistente y esta aplicación se duplica en varios servidores, cada servidor tiene su propio temporizador no persistente que se ejecuta dentro de ese entorno de servidor. Un temporizador no persistente creado mediante programación sólo se ejecuta en el miembro del clúster en el que se creó.
Al configurar un temporizador persistente en un entorno de varios servidores en clúster, considere las siguientes posibilidades para que la instancia de servidor invoque el método de tiempo de espera en un bean determinado:
- Base de datos del servicio de temporizador aparte por proceso servidor o miembro del clúster. Esta es la configuración predeterminada. La instancia de servidor o el miembro de clúster que han creado el temporizador son los únicos que pueden acceder al temporizador y ejecutar el método de tiempo de espera del bean. Si la instancia del servidor no está disponible, el temporizador no se ejecuta en el momento especificado y no se ejecuta hasta que no se reinicia el servidor. Además, si un enterprise bean llama al método getTimers(), sólo se encuentran los temporizadores creados en la instancia del servidor. Esto puede provocar un comportamiento inesperado si el enterprise bean intenta cancelar todos los temporizadores asociados a éste; por ejemplo, cuando se elimina el enterprise bean. Esta configuración NO se recomienda para sistemas de nivel de producción.
- La base de datos del servicio de temporizador común o compartido del clúster. Los temporizadores se pueden crear o se puede acceder a éstos en cualquier proceso servidor o miembro del clúster. Los temporizadores creados en un proceso servidor se buscan mediante el método getTimers() en otros procesos servidores del clúster. Cuando se elimina un bean de entidad, se cancelan todos los temporizadores, no importa dónde se hayan creado. No obstante, todos los temporizadores se ejecutan en un solo servidor del clúster, es decir, el método ejbTimeout se ejecuta para todos los temporizadores en un solo servidor. Qué servidor ejecuta los temporizadores varía en función de qué proceso servidor obtiene un bloqueo en las tablas de base de datos comunes. Si el servidor que ejecuta los temporizadores pasa a no estar disponible, entonces otro servidor o miembro del clúster lo sustituye y comienza a ejecutar todos los temporizadores a sus horas planificadas. Esta es la configuración recomendada para todos los sistemas de nivel de producción.
- Para evitar esto, utilice el intento de acceso de wsPessimisticUpdate. Este intento de acceso provoca que el método finder de la aplicación ejecute una sentencia select for update en lugar de una sentencia select genérica. Esto a su vez impide el punto muerto de escalación de bloqueo cuando varias hebras intentan escalar sus bloqueos para realizar una actualización.
Avoid trouble: Cuando utiliza el servicio EJB Timer en una aplicación con acceso a base de datos de varias hebras, el flujo de la aplicación puede presentar problemas de punto muerto.gotcha


