Transacciones de flujo de mensajes

Los flujos de mensajes soportan dos estilos de transacción:
  1. Las Flujos de mensajes coordinados aseguran que todas las actualizaciones en recursos se confirmen o restituyan juntas en una sola transacción.
  2. Las Flujos de mensajes no coordinados permiten que se produzcan actualizaciones en recursos de forma independiente; las actualizaciones no quedan afectadas por el éxito o la anomalía general del flujo.

Flujos de mensajes coordinados

Un flujo de mensajes que incluye la interacción con una base de datos externa u otro recurso recuperable se puede configurar de forma que todo el proceso se coordine en una sola transacción global. Esta coordinación asegura que todo el proceso se complete satisfactoriamente o que no se realice ningún proceso. La transacción se confirma (si todo el proceso es satisfactorio) o restituye (si una parte del proceso, como mínimo, no es satisfactoria). Esto significa que todos los recursos afectados (colas, bases de datos, etc) se mantengan en un estado coherente y que se conserve la integridad de datos.

Las actualizaciones realizadas por un flujo coordinado se confirman cuando el flujo termina de procesar satisfactoriamente el mensaje de entrada. Las actualizaciones se restituyen si:
  1. Cualquier nodo del flujo genera una excepción que sólo capta el nodo de entrada y
  2. El terminal de captación del nodo de entrada no se conecta.

Para configurar un flujo de mensajes como coordinado, establezca la propiedad Coordinado en el flujo de mensajes.

Para algunos nodos de entrada, por ejemplo MQInput, o nodos SCADA, puede establecer la propiedad Modalidad de transacción en los nodos del flujo en Automática; esto significa que los mensajes formarán parte de la transacción global y el flujo se marcará como transaccional, si el mensaje de entrada es persistente, y como no coordinado, si el mensaje de entrada no es persistente. Los nodos subsiguientes del flujo que establecen la propiedad de modalidad de transacción en Automática se incluyen en la transacción global si el nodo de entrada ha marcado el flujo como flujo de transacción.

La coordinación de transacción de los flujos de mensajes la proporciona WebSphere MQ en las plataformas distribuidas y RRS en los sistemas z/OS. Los flujos de mensajes se coordinan siempre globalmente en z/OS, independientemente de que la propiedad Coordinado del flujo de mensajes se haya especificado como coordinado o no.

Flujos de mensajes no coordinados

Los flujos no coordinados son flujos para los que no se ha establecido la propiedad Coordinado. Las actualizaciones en los recursos utilizados por un flujo no coordinado las gestionan los gestores de recursos independientes. Algunos gestores de recursos, por ejemplo WebSphere MQSeries, permiten que las actualizaciones se realicen sin transacciones o como parte de una transacción específica de recurso. Otros gestores de recursos, por ejemplo gestores de bases de datos, utilizan siempre una transacción específica de recurso. Una transacción específica de recurso es una transacción cuyo ámbito está limitado a los recursos que son propiedad de un solo gestor de recursos, por ejemplo un gestor de bases de datos o de colas.

Normalmente las transacciones específicas de recurso sólo se utilizan cuando sólo hay un tipo de recurso recuperable utilizado en un flujo. (Un flujo que contiene un nodo MQInput y un nodo MQOutput pero que no accede a ninguna base de datos es un ejemplo de este tipo de flujo.) No se deben utilizar transacciones específicas de recurso cuando hay más de un recurso y se debe mantener la integridad de datos.

Las actualizaciones realizadas en un recurso al que se accede sin transacciones se confirman inmediatamente. Un nodo MQInput configurado para no tener transacciones elimina los mensajes de la cola inmediatamente y si el flujo falla, se pierden los mensajes.

Algunos nodos de entrada, por ejemplo MQInput, o nodos SCADA, pueden formar parte de una transacción, en función de la persistencia del mensaje de entrada, estableciendo la modalidad de transacción en Automática. Los mensajes pasan a formar parte de la transacción y el flujo se marca como flujo de transacciones, si el mensaje de entrada es persistente, y como flujo sin transacciones, si el mensaje no es persistente.

El Ejemplo Manejador de errores muestra la utilización de transacciones coordinadas globalmente y la diferencias en el flujo de mensajes cuando las actualizaciones de base de datos están coordinadas (flujo principal) y cuando no lo están (flujo de errores).

Conceptos relacionados
Visión general de flujos de mensajes
Tareas relacionadas
Crear un flujo de mensajes
Definir el contenido del flujo de mensajes
Configurar flujos de mensajes coordinados
Manejar errores en flujos de mensajes
Referencia relacionada
Nodos incorporados
Conexiones de base de datos para flujos de mensajes coordinados
Soporte de base de datos para flujos de mensajes coordinados
Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Su opinión
Copyright IBM Corporation 1999, 2006 Última actualización: 22/08/2006
ac00645_