Una transacción describe un conjunto de actualizaciones realizadas por un programa de aplicación, que deben gestionarse juntas. Las actualizaciones pueden realizarse en uno o más sistemas. Las actualizaciones realizadas por el programa las controla el entorno en el que se ejecuta el programa y se llevan a cabo todas o ninguna. Esta propiedad de una transacción se conoce como coherencia: las transacciones pueden tener otras propiedades de atomicidad, aislamiento y durabilidad.
WebSphere Message Broker da soporte a transacciones y cada segmento de datos procesado por un flujo de transacciones tiene una transacción asociada. Una transacción de flujo de mensajes la empieza un intermediario cuando se reciben datos de entrada en un nodo de entrada del flujo; se compromete cuando el flujo ha terminado con ese mensaje o se retrotrae si se produce un error.
Si el flujo contiene más de un nodo de entrada, se inicia una transacción para cada nodo de entrada cuando éste recibe datos de entrada. Se inicia una transacción para cada tipo de nodo de entrada, incluidos los nodos de entrada definidos por el usuario.
Los nodos que incluye en el flujo de mensajes proporcionan un proceso específico de un mensaje, en función de la función definida de cada nodo. El proceso que llevan a cabo incluye trabajo interno sobre el que puede influir configurando las propiedades de nodo. Algunos nodos llevan a cabo tareas adicionales que pueden afectar a sistemas que son externos al flujo de mensajes o al intermediario.
Si un sistema externo, como una base de datos, da soporte al concepto de confirmación y retrotracción, y puede tomar parte en una transacción de intermediario, puede configurar el nodo de modo que el trabajo que lleve a cabo se incluya en la transacción del flujo. En función del nodo también puede especificar si el trabajo realizado en un sistema externo que da soporte a transacciones se confirma inmediatamente, o cuando finalice la transacción de flujo de mensajes.
Muchos de los recursos con los que puede interactuar los flujos de mensajes están controlados por gestores de recursos que pueden participan en transacciones coordinadas; por ejemplo, bases de datos, mensajes y colas de WebSphere MQ y mensajes JMS. Otros gestores de recursos no proporcionan soporte transaccional, por ejemplo, el protocolo HTTP y los sistemas de archivos.
Si el recurso puede participar en una transacción, se puede configurar de modo que el trabajo que realice se confirme o retrotraiga sólo cuando se complete el flujo de mensajes, o cuando el nodo se completa. Las bases de datos y colas de WebSphere MQ con ejemplos de recursos que puede utilizar de esta forma. Si el recurso no tiene un comportamiento transaccional, todo el trabajo que lleva a cabo se confirma inmediatamente. Por ejemplo, los archivos y conexiones HTTP no dan soporte a transacciones.
Las actualizaciones que realiza un flujo de mensajes se confirman cuando el flujo procesa satisfactoriamente el mensaje de entrada. Las actualizaciones se retrotraen si se cumplen las dos condiciones siguientes:
En sistemas distribuidos, las transacciones de flujos de mensajes las gestiona, de forma predeterminada, el intermediario. Estas transacciones se conocen como transacciones coordinadas por intermediario o transacciones coordinadas parcialmente. Cuando el control vuelve al nodo de entrada cuando el flujo finaliza el proceso, el nodo confirma o retrotrae las operaciones que se han realizado, excluyendo los nodos individuales que se han configurado para realizar sus propias confirmaciones y retrotracciones, que no dan soporte a esta opción.
Si el flujo de mensajes accede a más de un recurso, puede producirse un error que impide que todos los recursos confirmen todo el trabajo que se ha llevado a cabo. El intermediario genera una excepción y maneja el proceso de excepciones de una forma determinada por el transporte implicado. Por ejemplo, los mensajes que se han leído de las colas de WebSphere MQ se restauran en dichas colas, y se envían mensajes de error a las aplicaciones que han enviado un mensaje a través de HTTP (porque HTTP no tiene el concepto de retrotracción). Debido a estas acciones, el estado de los recursos puede pasar a ser incoherente.
Si es importante que los datos y las operaciones sigan siendo coherentes, y que todas las operaciones se hayan confirmado, o retrotraído, si una o más operaciones fallan, puede coordinar la actividad del flujo de mensajes. La coordinación la ofrece un gestor de transacciones externo que utiliza protocolos XA para interactuar con gestores de recursos. El nodo de entrada llama al gestor de transacciones cuando el flujo de mensajes haya finalizado (satisfactoriamente o con errores). El gestor de transacciones, en lugar del nodo de entrada y el intermediario, interectúa con los gestores de recursos pertinentes para iniciar las acciones correctas para cada recurso. Las transacciones que están controladas por un gestor de transacciones de esta forma se conocen como transacciones coordinadas globalmente.
En z/OS, las transacciones siempre están coordinadas globalmente; no tiene que seleccionar o configurar esta opción.
Para obtener una descripción más detallada del modelo de transacción en el intermediario, consulte El modelo transaccional.
El resultado de las acciones realizadas por los flujos de mensajes es el mismo para las transacciones coordinadas parcialmente que para las transacciones coordinadas globalmente si el flujo de mensajes es satisfactorio en todas sus acciones. La ventaja de una transacción coordinada globalmente es la capacidad de asegurarse de que todas las acciones están confirmadas, o ninguna.
El gestor de transacciones externo, que maneja una estrategia de confirmación de dos fases, da soporte a casos donde uno o más gestores de recursos externos están temporalmente no disponibles durante el proceso de confirmación. Este potencial intervalo pequeño para el error puede ser muy costoso para el entorno empresarial; el gestor de transacciones externo ayuda a eliminar que se produzca un intervalo de anomalías. Por consiguiente, la decisión de incluir un gestor de transacciones externo, que incluye una sobrecarga en el rendimiento, es una decisión administrativa, no una que debe tomarse durante el diseño del flujo de mensajes.
Un gestor de transacciones externo no evita que se pierdan mensajes; incluso si utiliza la coordinación de transacciones, deberá configurar y codificar los flujos de mensajes para que gestionen errores potenciales tanto como pueda.
Para configurar un flujo de mensajes para que esté coordinado globalmente, también deberá configurar el entorno de modo que sus gestores de recursos se hayan definido para el gestor de transacciones soportado:
Esta configuración puede requerirle cambiar los valores en el gestor de transacciones así como los gestores de recursos participantes.
Debe utilizar conexiones ODBC distintas si desea incluir nodos con el estado de transacción Automático y nodos con el estado de transacción Confirmar en el mismo flujo de mensajes, en el que los nodos operan en la misma base de datos externa. Configure una conexión para los nodos que no deben confirmar hasta la finalización del flujo de mensajes, y una segunda conexión para los nodos que deben confirmar de forma inmediata.
En sistemas distintos de z/OS, las bases de datos relacionales pueden no soportar
esta modalidad de operación.
Si define más de una conexión ODBC para el mismo origen de datos, es posible que se produzcan problemas de bloqueo de base de datos. En concreto, si un nodo con el estado de transacción 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 confirmará sus operaciones y liberará el bloqueo cuando finaliza el flujo. Sin embargo, el flujo no puede completarse porque el segundo nodo está a la espera de que el primer nodo libere el bloqueo de la base de datos.
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.
Para evitar este tipo de problema de bloqueo, puede utilizar una de las dos siguientes opciones:
Para obtener información relacionada con los objetos de base de datos que están bloqueados por determinadas operaciones y cómo configurar el parámetro de tiempo de espera de bloqueo, consulte la documentación del producto de base de datos.
Puede ver información sobre los ejemplos sólo cuando utilice el Information Center que está integrado en WebSphere Message Broker Toolkit o el Information Center en línea. Puede ejecutar ejemplos sólo cuando utilice el Information Center que está integrado en WebSphere Message Broker Toolkit.