El modelo transaccional

Un flujo de mensajes puede estar compuesto por las siguientes partes integrantes:

A continuación se describe una secuencia típica de sucesos cuando un flujo de mensajes procesa un mensaje:

  1. Se extrae un mensaje de la cola de entrada.
  2. Se leen datos de las tablas de base de datos y las colas, o se graban datos en ellas.
  3. El sistema está inactivo y a la espera del siguiente mensaje de entrada.

Tenga en cuenta que esta secuencia de sucesos no hace una distinción entre el acceso a las tablas y la grabación de mensajes de salida. Aunque un flujo genera a menudo alguna clase de mensaje de salida, no hay ninguna diferencia real entre generar un mensaje de salida y actualizar una base de datos; en ambos casos, el estado de los datos del sistema cambia.

Observe el diagrama siguiente:
	=====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 extrae de la cola de entrada. En los puntos 2, 3, 4 y 5, los datos se utilizan para actualizar tablas de base de datos o se graban en colas. 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. En medio de estos sucesos, no hay ningún cambio en el estado de los datos; esto 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 tablas y colas que se realizaron antes de la anomalía se habrán llevado a cabo, 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 un fallo 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.

Transacciones

Para evitar el problema descrito anteriormente, el intermediario, los sistemas de gestión de colas y las bases de datos tienen un modelo transaccional. A medida que avanza el proceso, se almacenan datos adicionales que permiten restaurar el estado original en el caso de una anomalía. El diagrama siguiente ilustra el estado de estos datos adicionales:
	-----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, un mensaje llega y se extrae de la cola de entrada. Antes del punto 1, no hay ningún dato adicional en el sistema; esto se indica en el diagrama mediante el símbolo -. Después del punto 1, el estado representa el hecho de que un mensaje se ha extraído de la cola de modo que éste se pueda volver a poner en la cola si es necesario. En los puntos 2, 3, 4 y 5, los datos se utilizan para actualizar tablas de base de datos o se graban en colas. De nuevo, el estado de los datos adicionales cambia a fin de que los cambios realizados en tablas y colas puedan deshacerse en caso necesario. En el punto 6, los mensajes de salida se envían, el sistema está inactivo y, de nuevo, no hay ningún dato adicional en el sistema. En medio de estos sucesos, no hay ningún cambio en el estado de los datos adicionales y esto se indica en el diagrama mediante el símbolo =. Si se produce una anomalía en algún momento entre el punto 1 y el punto 6, los datos adicionales se utilizan para restaurar el estado original de los datos del sistema, de modo que, en realidad, no se ha grabado ningún dato en las colas de salida, ninguna de las tablas se ha actualizado y el mensaje de entrada no se ha extraído de la cola 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).

La modalidad de operación que se ha descrito anteriormente 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.

Transacciones auxiliares no coordinadas

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 las colas y tablas que están asociadas 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:

Para satisfacer estos requisitos, WebSphere Message Broker permite que los cambios en colas y tablas se lleven a cabo en una transacción independiente. Este comportamiento se ilustra en el diagrama siguiente:
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 necesitan 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 realiza una actualización en una tabla o cola, y se realiza otra actualización en el punto 6. En el punto 7, el flujo de mensajes determina que todos los cambios que han de realizarse en la transacción auxiliar se han completado y confirma los cambios.

Si el flujo de mensajes fallase 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 pero la transacción principal se restituiría. Si se llega al punto 9 sin que se haya producido una anomalía, se confirman las dos transacciones.

Transacciones auxiliares de base de datos

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 de modo que, si el flujo de mensajes actualiza tablas que pertenecen a diferentes instancias de base de datos (nombres de orígenes de datos distintos), hay una transacción auxiliar para cada base de datos. Debe confirmar o restituir estas transacciones individualmente. Todas las actualizaciones que no se han confirmado ni restituido cuando finaliza la operación (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.

Algunos tipos de bases de datos, como por ejemplo DB2 en AIX, no permiten transacciones coordinadas y no coordinadas en la misma instancia de base de datos. En estos casos, debe crear instancias de base de datos separadas. Configure una instancia de base de datos para transacciones coordinadas y configure la otra instancia para transacciones no coordinadas.

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).

Transacciones auxiliares de cola

No todos los sistemas de gestión de colas tienen la posibilidad de base de datos que se ha descrito anteriormente. En el caso de 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, de modo que no puede colocar dos mensajes y luego decidir confirmar o restituir ambos. Por tanto, las sentencias COMMIT y ROLLBACK sólo funcionan en bases de datos.

Nodos

En la descripción anterior se mencionan los flujos de mensajes pero no se mencionan 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, múltiples nodos pueden realizar actualizaciones en la transacción principal y en múltiples transacciones auxiliares, sin ninguna restricción.

Transacciones totalmente no coordinadas

Cuando todas las actualizaciones de base de datos se realicen dentro de transacciones auxiliares, establezca el atributo Transacción coordinada del flujo de mensajes en no para que afecte a todas las referencias de tabla fuera de la transacción principal. Esto significa que no tiene que especificar el atributo en cada operación de base de datos.

Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Su opinión
Copyright IBM Corporation 1999, 2006 Última actualización: 22/08/2006
ac07010_