Un flujo de mensajes puede considerarse formado por las siguientes partes constituyentes:
Puede considerarse que la secuencia de sucesos que se dan cuando un flujo procesa un mensaje es:
Tenga en cuenta que esta secuencia de sucesos no hace distinciones entre el acceso a tablas y la grabación de mensajes de salida. Aunque se suele pensar en un flujo como producción de algún tipo de mensaje de salida, en realidad no existe ninguna diferencia entre esto y la actualización de una tabla de base de datos. En ambos casos se produce un cambio en el estado de los datos del sistema.
=====x=========x===x=======x=============x====x===== 1 2 3 4 5 6
La línea representa los datos del sistema conforme pasa el tiempo. En el momento 1 el mensaje llega y se coge de la cola de entrada. En los momentos 2, 3, 4 y 5, se actualizan las tablas de base de datos o se graban colas en las tablas. Estos cambios de estado están indicados con el símbolo x. Finalmente, en el momento 6, los mensajes de salida salen y el sistema queda inactivo. Entre estos sucesos no se producen cambios en el estado de los datos, lo cual está indicado con el símbolo =.
Consideremos ahora el efecto de las anomalías en el sistema. Si una anomalía, (p. ej. la máquina en la que se está ejecutando el intermediario se desenchufa), los cambios de estado de las tablas y colas realizados antes de la anomalía tendrán lugar, pero aquéllos que deberían haberse realizado posteriormente no se llevarán nunca a cabo. Una situación así es seguramente inaceptable (p. ej. que un pago desde mi cuenta corriente a la cuenta de la hipoteca ha sido deducido de la tabla de la cuenta corriente pero no añadido a la tabla de la cuenta de la hipoteca).
=====x=========x===x=======x=============x====x===== 1 2 3 4 5 6
La línea representa los datos adicionales del sistema conforme pasa el tiempo. En el momento 1 el mensaje llega y se coge de la cola de entrada. Antes no hay datos adicionales en el sistema, lo cual se indica con el símbolo -. Después, el estado indica que un mensaje se ha cogido de la cola para que pueda transferirse de nuevo si es necesario. En los momentos 2, 3, 4 y 5, se actualizan las tablas de base de datos o se graban colas en las tablas. De nuevo, el estado de los datos adicionales cambia, para que los cambios realizados a las tablas y colas puedan deshacerse si es necesario. Finalmente, en el momento 6, los mensajes de salida salen, el sistema queda inactivo y de nuevo no hay datos adicionales en el sistema. Entre estos sucesos no se producen cambios en el estado de los datos adicionales, lo cual está indicado con el símbolo =. Si se produce una anomalía en cualquier momento entre 1 y 6, se utilizan los datos adicionales para restablecer el estado original de los datos del sistema, de manera que, a efectos prácticos, no se ha grabado en las colas de salida, ninguna de las tablas se ha modificado y el mensaje de salida no se ha cogido de la cola de entrada. Si no se produce ninguna anomalía, los cambios serán permanentes en el momento 6, es decir, una operación de deshacer debida a una anomalía posterior no los deshará.
Esta modalidad de operación se conoce como modalidad de transacción coordinada. La terminación con éxito de una transacción se conoce como su confirmación. Si no se ejecuta correctamente, se habla de restitución. (Consulte la sección XYZ para obtener una larga y complicada descripción de cómo conseguirlo y tenga en cuenta que no es la opción predeterminada y que no todas las bases de datos o sistemas de colas la soportan).
La característica clave de la modalidad de operación de la transacción coordinada es que bien se realizan todos los cambios en colas y tablas asociadas a un mensaje de entrada o bien no se realiza ninguno, independientemente de donde o cuando se produzcan las anomalías y en esa es la principal ventaja que tiene. Sin embargo no es adecuada para todas las situaciones. Dos ejemplos simples de tales situaciones:
PRAL -----x=========x===x=======x=============x====x----- 1 2 4 5 8 9 1ª AUX --------------x======x========x------ 3 6 7
La línea superior representa de nuevo la transacción principal. Transacción es un término bastante abstracto, pero a lo que equivale en el mundo real es a los datos adicionales que son necesarios para restaurar el estado original si hubiera que hacerlo. La línea inferior representa una transacción auxiliar. En el momento 3, se realiza una actualización en una tabla (o cola). En el momento 6, se realiza otra. En el momento 7, el flujo decide que todos los cambios que se han de hacer bajo la transacción auxiliar se han completado y confirma los cambios.
Si el flujo no se ejecuta correctamente antes del momento 7, el estado del sistema no sufrirá cambios, ya que ambas transacciones se habrán restituido. Si la anomalía se produce después del momento 7 pero antes del 9, la transacción auxiliar será confirmada (ya lo estaría) pero la principal se restituirá. Si no se produce ninguna anomalía hasta el momento 9, no hay anomalía y ambas transacciones se confirmarán.
No está limitado a una única transacción auxiliar ni a sólo confirmarlas. Se pueden realizar varias actualizaciones en tablas de base de datos, que pueden confirmarse o restituirse. A continuación puede realizar más cambios a las mismas tablas de base de datos o a otras tablas y después confirmar o restituir estos cambios.
Cada base de datos que utiliza tiene su propia transacción auxiliar y por tanto, si el flujo actualiza tablas que pertenecen a instancias de base de datos diferentes (por ejemplo, nombres de origen de datos diferentes) habrá una transacción auxiliar por cada base de datos. Estas pueden (de hecho, deben) confirmarse o restituirse de manera individual. El intermediario confirmará o restituirá automáticamente cualquier actualización que no se haya confirmado o restituido cuando la operación termina (momento 9), en función de si el proceso se ha ejecutado correctamente o no (es decir, si ha llegado una excepción al nodo de entrada o no).
Tenga en cuenta que algunos tipos de bases de datos, como por ejemplo DB2 y AIX, no permiten transacciones coordinadas y no coordinadas en la misma instancia de base de datos. En estos casos, se deben crear instancias de base de datos independientes. Debe configurar una instancia de base de datos para transacciones coordinadas y otra para transacciones no coordinadas.
Las transacciones de base de datos auxiliares se confirman o restituyen utilizando las sentencias ESQL COMMIT y ROLLBACK. Las operaciones fuera de la transacción principal se consiguen especificando UNCOORDINATED en las sentencias de la base de datos concreta que se utiliza, como por ejemplo las sentencias INSERT y UPDATE.
No todos los sistemas de gestión de colas tienen la posibilidad de las bases de datos que se han descrito anteriormente. En el caso de MQ, cada lectura o grabación en una cola implica una confirmación. Por tanto, no puede transferir dos mensajes y decidir después confirmar o restituir los dos. Esta es una limitación del sistema subyacente que WebSphere Message Broker no puede ocultar. Por tanto, las sentencias COMMIT y ROLLBACK sólo operan en bases de datos.
La descripción anterior sólo habla de flujos y no menciona los nodos. La manera en la que un flujo se divide en nodos es, en principio, irrelevante en una discusión sobre transacciones. Cualquier número de nodos puede hacer actualizaciones en la transacción principal y en cualquier número de transacciones auxiliares de cualquier manera que consideren adecuada sin restricciones. Lo que haga tiene importancia, pero no la manera de hacerlo. De todos modos, en la práctica, esto sólo es así para operaciones con bases de datos porque simplemente otros orígenes de datos (VSAM, Colas) tienen posibilidades más limitadas.
Un caso especial que merece la pena tratar es cuando todas las actualizaciones de bases de datos se hacen en transacciones auxiliares. En este caso el atributo "Transacción coordinada" del flujo de mensajes puede establecerse en "no". Así se hacen todas las referencias de tabla fuera de la transacción principal, ahorrándonos la molestia de tener que especificarlo en cada operación de base de datos. También puede hacer los flujos más rápidos.