Establezca la propiedad
Transacción para los
nodos siguientes si aparecen en este flujo de mensajes: - Compute
- Database
- DataDelete
- DataInsert
- DataUpdate
- Filter
- Mapping
- Warehouse
Puede establecer la propiedad
Transacción en los
valores siguientes:
- Automático
- Las actualizaciones, supresiones y adiciones que realiza el nodo se
confirman o restituyen cuando se completa el proceso del flujo de mensajes. Si el flujo de mensajes se completa satisfactoriamente, se confirman
todos los cambios. Si no se completa satisfactoriamente, se restituyen
todos los cambios.
Si desea que todos los procesos realizados por el
flujo de mensajes estén coordinados, debe seleccionar este valor.
- Confirmar
- La acción que se realiza depende del sistema en el que se ha desplegado
el flujo de mensaje:
Si desea mezclar nodos con transacciones de tipo
Automático y
Confirmar en el mismo flujo de
mensajes, donde los nodos funcionan en la misma base de datos externa,
debe utilizar conexiones ODBC aparte: una para los nodos que no se han de
confirmar hasta que el flujo de mensajes se complete y otra para los
nodos que se han de confirmar inmediatamente. Si no lo hace así, los
nodos que se confirman inmediatamente también confirmarán todas las
operaciones realizadas en los nodos
Automático
anteriores.
Nota: En
plataformas distintas de z/OS, es posible que las bases de datos relacionales individuales
soporten o no soporten esta modalidad de operación.
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 transacciones de tipo
Automático 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:
- Diseñe el flujo de mensajes de forma que las operaciones no
confirmadas (automáticas) no bloqueen ningún objeto de base de datos al
que necesiten acceder operaciones posteriores utilizando una conexión ODBC
distinta.
- Configure el parámetro de tiempo de espera de bloqueo de base de
datos de forma que un intento de obtener un bloqueo falle después de un
periodo de tiempo especificado. Si una operación de base de datos falla
debido al tiempo de espera de bloqueo de base de datos, se genera una
excepción que el intermediario maneja de forma normal.
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.
Establezca la propiedad
Modalidad de transacción
para los nodos siguientes, si aparecen en este flujo de mensajes: - MQInput
- MQOutput
- MQReply
- SCADAInput
- Nodo JMSInput
- Nodo JMSOutput
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 |
El flujo de mensajes está coordinado globalmente |
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 |
Notas: - La persistencia sólo es importante para los mensajes recibidos a través
de los protocolos WebSphere MQ Enterprise Transport, WebSphere
MQ Mobile Transport y WebSphere MQ Telemetry Transport.
- El valor de la propiedad de nodo MQOutput o MQReply prevalece sobre el
valor que se establece aquí.
- Los valores de Modalidad de transacción de los nodos JMSInput y JMSOutput
están establecidos de forma diferente a la de la tabla anterior. Consulte
Nodo JMSInput y Nodo JMSOutput para más información.
El valor por omisión en cada nodo de entrada es
Sí, que significa
que los mensajes de entrada se procesan bajo punto de sincronismo. Además,
los mensajes que se envían al nodo de salida se entregan bajo punto de
sincronismo. 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 en un nodo de entrada en
Automático, los
mensajes de entrada se procesan bajo punto de sincronismo sólo si están
definidos como persistentes. Los mensajes enviados al nodo MQOutput se entregan bajo punto de
sincronismo a menos que cambie, de forma explícita, la
Modalidad de transacción
en el nodo MQOutput.