El modelo transaccional describe la forma en la que puede utilizar transacciones en flujos de mensajes para llevar a cabo tareas y conseguir resultados determinados.
Un flujo de mensajes consta de las siguientes partes:
Los pasos siguientes representan una secuencia típica de sucesos en la transacción de flujo de mensajes:
Durante esta secuencia de sucesos, el estado de los datos del sistema cambia, independientemente del número de recursos externos a los que accede el flujo de mensajes y de si genera un mensaje de salida.
-----x---------x---x-------x-------------x----x-----
1 2 3 4 5 6
La línea representa los datos en el sistema a medida que pasa el tiempo. En el punto 1, un mensaje llega y se toma del origen de entrada. En los puntos 2, 3, 4 y 5, los datos se utilizan para actualizar recursos externos; por ejemplo, una tabla de base de datos o una cola de salida. Los cambios en el estado de los datos se indican en el diagrama mediante el símbolo x. En el punto 6, los mensajes de salida se envían y el sistema está inactivo. Entre estos sucesos, el estado de los datos no cambia; este estado se indica en el diagrama mediante el símbolo =.
Si se produce una anomalía en el sistema (por ejemplo, una caída de alimentación en el sistema en el que se está ejecutando el intermediario), los cambios en el estado de recursos externos que se realizaron antes de la anomalía se habrán implementado, pero no se llevarán a cabo más cambios después de la anomalía. Esta situación es inaceptable en determinadas circunstancias; por ejemplo, si se produce una anomalía del sistema al realizar un pago de una cuenta corriente a una cuenta hipotecaria, el pago puede haberse sacado de la cuenta corriente, pero no se ha ingresado en la cuenta hipotecaria.
Para evitar el problema descrito anteriormente, el intermediario y los gestores de recursos externos con los que trabaja, tenga un modelo transaccional. El intermediario inicia una transacción cuando un nodo de entrada del flujo de mensajes recibe datos y acaba cuando finaliza el proceso de dichos datos. Para obtener más detalles sobre las transacciones de flujos de mensajes, consulte Transacciones de flujo de mensajes.
-----x=========x===x=======x=============x====x-----
1 2 3 4 5 6
La línea del diagrama representa los datos adicionales en el sistema a medida que pasa el tiempo. En el punto 1, los datos de entrada llegan del origen de entrada; por ejemplo, una cola. Antes del punto 1, no existen datos adicionales en el sistema; este estado se indica en el diagrama mediante el símbolo -. Después del punto 1, el estado representa el hecho de que los datos se han recibido del origen de entrada, de modo que se pueda restaurar si es necesario. En los puntos 2, 3, 4 y 5, los datos se utilizan para actualizar recursos externos, como bases de datos o archivos. De nuevo, el estado de los datos adicionales cambia a fin de que los cambios realizados en esos recursos externos puedan deshacerse en caso necesario. En el punto 6, los mensajes de salida se envía, el sistema está inactivo y los datos adicionales del sistema dejan de existir.
Entre esos sucesos, el estado de los datos adicionales no cambia; este estado se indica mediante el símbolo =. Si se produce una anomalía entre el punto 1 y el punto 6, los datos adicionales se utilizan para restaurar el estado original de los datos retenidos por los recursos externos. Por lo tanto, en realidad no se ha grabado ningún dato de salida en el destino de salida, no se ha actualizado ninguno de los recursos externos y los datos de entrada no se han recibido del origen de entrada. Si no se produce ninguna anomalía, los cambios se hacen permanentes en el punto 6 (una operación de deshacer realizada después de una anomalía posterior no deshará los cambios).
Esta modalidad de operación se conoce como modalidad de transacción coordinada. La finalización satisfactoria de una transacción recibe el nombre de confirmación. La finalización no satisfactoria recibe el nombre de restitución.
La característica clave de la modalidad de operación de transacción coordinada es que, independientemente de dónde o cuándo aparece la anomalía, o bien se realizan todos los cambios en recursos externos que están asociados a un mensaje de entrada, o no se realiza ninguno de los cambios. No obstante, este comportamiento no siempre es adecuado, como se explica en los siguientes ejemplos:
Si los flujos de mensajes tienen tales requisitos, puede configurar flujos de mensajes para cambiar uno o más recursos en una transacción independiente o auxiliar. No todos los gestores de recursos dan soporte a este tipo de transacción.
Para algunos recursos, se inicia automáticamente una transacción auxiliar; por ejemplo, cada conexión de base de datos inicia una transacción que es específica a esa base de datos y todas las actualizaciones realizadas en esa transacción se comprometen o retrotraen.
PRINCIPAL -----x=========x===x=======x=============x====x-----
1 2 4 5 8 9
1era AUX --------------x======x========x------
3 6 7
La línea PRINCIPAL representa la transacción principal, que incluye los datos adicionales que se registran para restaurar el estado original en caso de que fuera necesario. La línea 1era AUX representa una transacción auxiliar. En el punto 3, se actualiza un recurso externo, y se realiza otra actualización en el punto 6. En el punto 7, el flujo de mensajes determina que todos los cambios que deben realizarse en la transacción auxiliar se han completado y confirma los cambios.
Si el flujo de mensajes falla antes del punto 7, el estado del sistema no cambiaría porque ambas transacciones se restituirían. Si se produce una anomalía después del punto 7 pero antes del punto 9, la transacción auxiliar ya se habría confirmado. Sin embargo, la transacción principal se retrotraerá. Si se llega al punto 9 sin que se haya producido una anomalía, se confirman las dos transacciones.
Puede utilizar más de una transacción auxiliar y realizar varias actualizaciones en tablas de base de datos que se pueden confirmar o restituir. Después puede realizar más cambios en las mismas tablas de base de datos, o en otras distintas, y luego confirmar o restituir estos cambios.
Cada base de datos que utiliza tiene su propia transacción auxiliar; por lo tanto, si el flujo de mensajes actualiza tablas que pertenecen a instancias diferentes de bases de datos (nombres de origen de datos distintos), hay una transacción auxiliar para cada base de datos. Opcionalmente puede confirmar o retrotraer estas transacciones auxiliares de forma individual. Las actualizaciones que no se han confirmado ni restituido cuando finaliza el flujo de mensaje (en el punto 9 del ejemplo anterior), las confirma o restituye automáticamente el intermediario, en función de si el proceso se ha realizado satisfactoriamente o no.
Utilice las sentencias COMMIT y ROLLBACK de ESQL para confirmar y restituir transacciones auxiliares de base de datos. Para obtener operaciones fuera de la transacción principal, especifique la palabra clave UNCOORDINATED en las sentencias de base de datos individuales (por ejemplo, las sentencias INSERT y UPDATE).
No todos los sistemas de gestión de colas tienen la posibilidad de base de datos que se ha descrito en la sección anterior. Con WebSphere MQ, cada operación individual no coordinada de lectura o grabación en una cola tiene una acción de confirmación implícita. Por lo tanto, no puede colocar mensajes y luego decidir confirmar o restituir ambos. Por tanto, las sentencias COMMIT y ROLLBACK sólo funcionan en bases de datos.
En las secciones anteriores se hacía referencia a los flujos de mensajes pero no a los nodos. La forma en que un flujo de mensajes está dividido en nodos no afecta para nada a las transacciones. Para operaciones en bases de datos, una cantidad ilimitada de nodos puede realizar actualizaciones en la transacción principal y una cantidad ilimitada de transacciones auxiliares, sin ninguna restricción.