Si desea coordinar el proceso de flujo de mensajes con otros recursos, debe configurar las propiedades, tanto de los nodos dentro del flujo de mensajes como del flujo de mensajes mismo.
Un flujo de mensajes coordinado se ejecuta en una sola transacción, que se inicia cuando un nodo de entrada recibe un mensaje y se puede confirmar o restituir cuando se ha completado todo el proceso. También puede controlar cómo maneja los errores de base de datos el nodo que interactúa con la base de datos.
Para configurar el flujo de mensajes y los nodos:
Puede establecer la propiedad Transacción en los valores siguientes:
Si desea que todos los procesos realizados por el flujo de mensajes estén coordinados, debe seleccionar este valor.
Si define más de una conexión ODBC, es posible que se produzcan problemas de bloqueo de base de datos. En concreto, si un nodo con transaccionalidad Automática lleva a cabo una operación, como INSERT o UPDATE, se bloquea un objeto de base de datos (por ejemplo, una tabla) y si otro nodo intenta acceder a ese objeto de base de datos utilizando una conexión ODBC distinta, se produce un bloqueo persistente.
El segundo nodo espera que se libere el bloqueo provocado por el primer nodo, pero éste no confirmará sus operaciones y liberará el bloqueo hasta que se complete el flujo de mensajes; esto no sucederá porque el segundo nodo está esperando a que se libere el bloqueo de la base de datos del primer nodo.
Una situación así no la puede detectar ninguna rutina automática DBMS para evitar los bloqueos persistentes, porque las dos operaciones se interfieren la una con la otra indirectamente, utilizando el intermediario.
Hay dos maneras de evitar este tipo de problemas de bloqueo:
Para obtener información sobre los objetos de base de datos que ciertas operaciones bloquean, y cómo configurar el parámetro de tiempo de espera de bloqueo de base de datos, consulte la documentación del producto de base de datos.
La tabla siguiente proporciona un resumen de las acciones que se toman en respuesta a valores específicos de las propiedades para los nodos de entrada y salida.
Persistencia de mensajes a | Modalidad de transacción del nodo Input | Modalidad de transacción del nodo MQOutput o MQReply | ¿Está globalmente coordinado el flujo de mensajes? |
---|---|---|---|
Sí | Sí | Automática | Sí |
No | Sí | Automática | Sí |
Sí | No | Automática | No |
No | No | Automática | No |
Sí | Automática | Automática | Sí |
No | Automática | Automática | No |
Cualquiera b | Cualquiera b | Sí | Sí |
Cualquiera b | Cualquiera b | No | No |
El valor por omisión en cada nodo de entrada es Sí, que significa que los mensajes de entrada se procesan bajo punto de sincronización. Además, los mensajes que se envían al nodo de salida se entregan bajo punto de sincronización. Puede cambiar este comportamiento si el nodo de salida es un nodo MQOutput o MQReply, los dos tienen una propiedad Modalidad de transacción.
Si establece la Modalidad de transacción de un nodo de entrada en Automática, los mensajes de entrada se procesan bajo punto de sincronización sólo si están definidos como persistentes. Los mensajes enviados al nodo MQOutput se entregan bajo punto de sincronización a menos que cambie, de forma explícita, la Modalidad de transacción en el nodo MQOutput.
En z/OS, las transacciones siempre están coordinadas globalmente. Se hace caso omiso del valor de la propiedad Transacción coordinada para un flujo de mensajes. La coordinación siempre la proporciona RRS.