Beans controlados por mensajes: soporte de transacciones

Los beans controlados por mensajes pueden manejar mensajes en destinos (o puntos finales) dentro del ámbito de una transacción.

Manejo de transacciones cuando se utiliza el Servicio de escucha de mensajes con IBM MQ JMS

Hay tres casos posibles, basados en el valor del descriptor de despliegue de bean controlado por mensaje que seleccione: la transacción gestionada por contenedor (necesaria), la transacción gestionada por contenedor (no soportada) y la transacción gestionada por bean.

En los valores del descriptor de despliegue de bean controlado por mensaje, puede elegir si el bean controlado por mensaje gestiona sus propias transacciones (transacción gestionada por bean) o si un contenedor gestiona transacciones de parte del bean controlado por mensaje (transacción gestionada por contenedor). Si elige transacciones gestionadas por contenedor, en el cuaderno del descriptor de despliegue, puede seleccionar un tipo de transacción de contenedor para cada método del bean para determinar si las transacciones de contenedor son necesarias o si no reciben soporte. El tipo de transacción de contenedor predeterminado es necesario.

Transacción gestionada por contenedor (necesaria)

En este caso, el servidor de aplicaciones inicia una transacción global antes de leer el mensaje de entrada desde el destino y antes de que el servidor de aplicaciones invoque el método onMessage() de bean controlado por mensajes. Esto significa que otros EJB que el mensaje invoca a su vez y las interacciones con recursos como, por ejemplo, las bases de datos, pueden estar dentro del ámbito de esta transacción global individual, en la que se ha obtenido el mensaje de entrada.

Si este flujo de aplicaciones se completa correctamente, se compromete la transacción global. Si el flujo no se completa correctamente, (si la transacción se ha marcado para restitución o si se produce una excepción de tiempo de ejecución), se restituye la transacción y el mensaje de entrada se vuelve a restituir al destino del bean controlado por mensaje.

Transacción gestionada por contenedor (no soportada)

En este caso, no hay transacción global pero el proveedor de JMS puede continuar entregando un mensaje desde un destino de bean controlado por mensajes al servidor de aplicaciones de una unidad de trabajo. Puede considerarla una transacción global, ya que no implica a otros recursos en su ámbito de transacción.

El servidor de aplicaciones reconoce la entrega de los mensajes cuando se ha asignado correctamente el onMessage() del bean controlado por mensajes (utilizando la modalidad de reconocimiento que ha especificado el ensamblador del bean controlado por mensaje).

No obstante, el servidor de aplicaciones no realiza un reconocimiento si durante la ejecución se genera una excepción sin comprobar procedente del método onMessage(). Por lo tanto, el mensaje se restituye otra vez al destino del bean controlado por mensajes. ¿O se reconoce y suprime?

La respuesta depende de si el proveedor de JMS de utiliza un punto de sincronización y puede variar dependiendo de la plataforma operativa (en particular, la plataforma operativa z/OS puede comportarse aquí de modo diferente).

Si el proveedor de JMS establece un punto de sincronización alrededor del consumo del mensaje del bean controlado por mensajes en este caso de transacción gestionada por contenedor (no soportado), el mensaje se vuelve a restituir al destino después de que se produzca una excepción sin comprobar.

Si no se utiliza un punto de sincronización, el mensaje se suprime del destino después de una excepción.

Para obtener información relacionada, consulte la nota técnica "El comportamiento de MDB es diferente en z/OS que en un entorno distribuido cuando se obtienen mensajes no permanentes en el punto de sincronismo" en http://www.ibm.com/support/docview.wss?uid=swg21231549.

Transacción gestionada por bean

En este caso, la acción es similar al caso de la transacción gestionada por contenedor (no soportada). Aunque en este caso puede haber una transacción de usuario, cualquier transacción de usuario iniciada en la asignación por parte de onMessage del bean controlado por mensajes no incluye el consumo del mensaje desde el destino del bean controlado por mensajes incluido en el ámbito de la transacción. Para ello, utilice el escenario de transacción gestionada por contenedor (necesaria)

Reentrega de mensajes

En cada uno de los tres casos anteriores, un mensaje que se ha restituido al destino del bean controlado por mensaje se vuelve a asignar. Si originalmente se ha restituido debido a un problema temporal del destino, puede presuponer que la reasignación del bean controlado por mensajes con este mensaje se realice correctamente. No obstante, si la restitución ha sido debida a un problema específico relacionado con el mensaje, el mensaje se restituirá y reasignará de forma repetida. Esto se conoce como un caso de mensaje con formato incorrecto.

Si el sistema de mensajería utiliza puertos de escucha, el servidor de aplicaciones maneja este escenario realizando un seguimiento de la frecuencia con la que se asigna un mensaje específico y deteniendo el puerto de escucha asociado después de que se haya producido un número especificado de intentos de reentregas.

Si el sistema de mensajería utiliza puertos de escucha, puede evitar el caso del mensaje con formato incorrecto configurando la propiedad siguiente:
Máximo de reintentos
El parámetro Máximo de reintentos especifica el número máximo de veces que el escucha intenta enviar un mensaje específico a una instancia de bean controlado por mensajes antes de detenerse.
Si este parámetro se establece en 0, el puerto de escucha se detendrá después de una sola anomalía en la entrega satisfactoria de un mensaje.
Para obtener más información acerca de esta propiedad, consulte Valores de puerto de escucha.

Si el sistema de mensajería utiliza especificaciones de activación, el escenario de mensaje con formato incorrecto se manejan de un modo ligeramente diferente. Mientras que los puertos de escucha realizan un seguimiento del número de veces que falla la entrega de un determinado mensaje y éste se vuelve a entregar, las especificaciones de activación cuentan el número de anomalías en la entrega de mensajes secuenciales.

Si el sistema de mensajería utiliza el proveedor de mensajería predeterminado (integración de servicio), debe configurar las propiedades siguientes en la especificación de activación para evitar un escenario de mensaje con formato incorrecto:
Detener automáticamente puntos finales en anomalía de mensaje repetida
Debe asegurarse de que esta opción esté seleccionada.
Esta propiedad suspende la entrega de mensajes al punto final cuando se alcanza el Umbral de mensaje anómalo secuencial.
Umbral de mensaje anómalo secuencial
Este parámetro determina cuántas entregas de mensaje pueden fallar antes de que se suspenda la entrega del mensaje.
Para habilitar este parámetro, debe tener seleccionada la opción Detener automáticamente los puntos finales en anomalía de mensaje repetida.
Retardo entre reintentos de mensaje anómalo
Este parámetro especifica cuánto tiempo debe transcurrir antes de que se vuelva a entregar un mensaje que no se ha podido entregar correctamente.
Si especifica 0 para este parámetro, no habrá ningún retardo antes de que se vuelva a entregar el mensaje.
Para habilitar este parámetro, debe tener seleccionada la opción Detener automáticamente los puntos finales en anomalía de mensaje repetida.
Si desea más información sobre estas propiedades, consulte Especificación de activación JMS [Valores].
Si el sistema de mensajería utiliza el proveedor de mensajería de IBM MQ, debe configurar las propiedades siguientes en la especificación de activación para evitar un escenario de mensaje con formato incorrecto:
Se detiene en el punto final si falla la entrega del mensaje
Debe asegurarse de que esta opción esté seleccionada.
Esta propiedad suspende la entrega de mensajes al punto final cuando se alcanza el Número de anomalías de entrega secuenciales antes de suspender el punto final.
Número de anomalías de entrega secuenciales antes de suspender el punto final
Este parámetro determina cuántas entregas de mensaje pueden fallar antes de que se suspenda la entrega del mensaje.
Para habilitar este parámetro, debe tener seleccionada la opción Detener el punto final si la entrega del mensaje falla.
Si desea más información sobre estas propiedades, consulte Propiedades avanzadas de la especificación de activación del proveedor de mensajería de IBM MQ

Como alternativa a basarse en el servidor de aplicaciones para detener el puerto de escucha o la especificación de activación si se produce un escenario de mensaje con formato incorrecto, puede configurar IBM MQ para resolver el problema. Para los destinos de cola, especifique una cola de restitución (BOQUEUE) y un valor de umbral de restitución (BOTHRESH) en el objeto de cola en IBM MQ. Para los destinos de cola, especifique una cola de restitución (BOQUEUE) y un valor de umbral de restitución (BOTHRESH) para las colas del sistema IBM MQ SYSTEM.DURABLE.MODEL.QUEUE y SYSTEM.NDURABLE.MODEL.QUEUE. Si lo hace, IBM MQ maneja el mensaje con formato incorrecto. Para obtener más información sobre el manejo de mensajes con formato incorrecto, consulte la sección IBM MQ Utilización de la sección Java™ de la biblioteca de IBM MQ.


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=cmb_trans
File name: cmb_trans.html