Gestión y soporte de transacciones

Introducción a la gestión de transacciones y cómo IBM® MQ da soporte a las transacciones.

Un gestor de recursos es un subsistema informático que posee y gestiona recursos a los que las aplicaciones pueden acceder y que pueden actualizar. A continuación, se muestran algunos ejemplos de gestores de recursos:

Un gestor de colas de IBM MQ, con recursos que son sus colas
Una base de datos Db2® , con recursos que son sus tablas

Cuando una aplicación actualiza los recursos de uno o varios gestores de recursos, es posible que haya un requisito empresarial para garantizar que determinadas actualizaciones se completan todas satisfactoriamente como un grupo o no se completará ninguna de ellas. El motivo de este tipo de requisito es que los datos empresariales podrían quedarse en un estado incoherente si sólo se completaran correctamente algunas de estas actualizaciones y otras no.

Las actualizaciones de los recursos que se gestionan de este modo se dice que ocurren dentro de una unidad de trabajo o una transacción. Un programa de aplicación puede agrupar un conjunto de actualizaciones en una unidad de trabajo.

Durante una unidad de trabajo, una aplicación emite peticiones a los gestores de recursos para actualizar sus recursos. La unidad de trabajo finaliza cuando la aplicación emite una petición para confirmar todas las actualizaciones. Hasta que las actualizaciones se confirmen, ninguna de ellas estará visible para las otras aplicaciones que acceden a los mismos recursos. De forma alternativa, si la aplicación decide que no puede completar la unidad de trabajo por algún motivo, puede emitir una petición para restituir todas las actualizaciones que haya solicitado hasta ese momento. En este caso, ninguna de las actualizaciones estará nunca visible para otras aplicaciones. Normalmente, estas actualizaciones están relacionadas lógicamente y deben ejecutarse todas satisfactoriamente para mantener la integridad de los datos. Si una actualización se ejecuta satisfactoriamente y otra no, se pierde la integridad de los datos.

Cuando una unidad de trabajo se ejecuta satisfactoriamente, se dice que se confirma. Una vez confirmada, todas las actualizaciones realizadas dentro de esa unidad de trabajo se convierten en persistentes e irreversibles. Sin embargo, si la unidad de trabajo no se ejecuta correctamente, todas las actualizaciones se restituyen. Este proceso, en el que las unidades de trabajo se confirman o se restituyen con integridad, se conoce como coordinación del punto de sincronismo.

El momento específico en el que todas las actualizaciones en una unidad de trabajo se han confirmado o se han restituido se denomina punto de sincronismo. Una actualización en una unidad de trabajo se dice que ocurre dentro del control de punto de sincronismo. Si una aplicación solicita una actualización que está fuera del control de punto de sincronismo, el gestor de recursos confirma inmediatamente la actualización, aunque haya una unidad de trabajo en curso, y la actualización no se puede restituir más tarde.

El subsistema informático que gestiona unidades de trabajo se denomina gestión de transacciones o coordinador de puntos.

Una unidad de trabajo de local es aquella en la que los únicos recursos actualizados son los del gestor de colas de IBM MQ. En ese caso, la coordinación del punto de sincronismo la proporciona el propio gestor de colas utilizando el proceso de confirmación en una sola fase.

Una unidad de trabajo global es aquella en la que los recursos que pertenecen a otros gestores de recursos, como bases de datos conformes a las normas XA, también se actualizan. Aquí, se debe utilizar un procedimiento de confirmación de dos fases y la unidad de trabajo puede ser coordinada por el propio gestor de colas, o externamente por otro gestor de transacciones compatible con XA como IBM TXSeries®o BEA Tuxedo.

Un gestor de transacciones es el responsable de garantizar que todas las actualizaciones de recursos en una unidad de trabajo se completen correctamente o bien ninguna de ellas se completa. Es a un gestor de transacciones a quien la aplicación emite una petición para confirmar o restituir una unidad de trabajo. Los ejemplos de gestores de transacciones son CICS® y WebSphere® Application Server, aunque ambos poseen también otra función.

Algunos gestores de recursos tienen su propia función de gestión de transacciones. Por ejemplo, un gestor de colas de IBM MQ puede gestionar unidades de trabajo que impliquen actualizaciones de sus propios recursos y actualizaciones en las tablas de Db2. El gestor de colas no necesita un gestor de transacciones independiente para realizar esta función, aunque se puede utilizar uno, en caso de que sea requisito del usuario. Si se utiliza un gestor de transacciones independiente, se denominará gestor de transacciones externo.

Para que un gestor de transacciones externo gestione una unidad de trabajo, debe haber una interfaz estándar entre el gestor de transacciones y cada gestor de recursos que participa en la unidad de trabajo. Esta interfaz permite que el gestor de transacciones y un gestor de recursos se comuniquen entre sí. Una de estas interfaces es la Interfaz XA, que es una interfaz estándar soportada por una serie de gestores de transacciones y gestores de recursos. La Interfaz XA está publicada por The Open Group en Distributed Transaction Processing: The XA Specification.

Cuando más de un gestor de recursos participa en una unidad de trabajo, un gestor de transacciones debe utilizar un protocolo de confirmación en dos fases para asegurarse de que todas las actualizaciones dentro de la unidad de trabajo se completan satisfactoriamente o bien ninguna de ellas se completará, aunque haya una anomalía en el sistema. Cuando una aplicación emite una petición a un gestor de transacciones para confirmar una unidad de trabajo, el gestor de transacciones realiza lo siguiente:

Fase 1 (preparar la confirmación): El gestor de transacciones pregunta a cada gestor de recursos que participa en la unidad de trabajo para asegurarse de que toda la información sobre las actualizaciones previstas de sus recursos esté en un estado recuperable. Normalmente, un gestor de recursos es quien lo hace grabando la información en un registro y asegurándose de que la información se graba a través del disco duro. La Fase 1 se completa cuando el gestor de transacciones recibe notificación de cada gestor de recursos de que la información sobre las actualizaciones previstas de sus recursos se encuentran en un estado recuperable.
Fase 2 (confirmar): Cuando la Fase 1 se ha completado, el gestor de transacciones toma la decisión irrevocable de confirmar la unidad de trabajo. Solicita a cada gestor de recursos que participa en la unidad de trabajo que confirme las actualizaciones de sus recursos. Cuando un gestor de recursos recibe esta petición, debe confirmar las actualizaciones. No tiene la opción de restituirlas en esta fase. La Fase 2 se completa cuando el gestor de transacciones recibe notificación de cada gestor de recursos de que ha confirmado las actualizaciones de los recursos.

La Interfaz XA utiliza un protocolo de confirmación en dos fases.

Para obtener más información, consulte Casos de ejemplo de soporte transaccional.

IBM MQ también proporciona soporte para Microsoft Transaction Server (COM+). Utilización de Microsoft Transaction Server (COM+) proporciona información sobre cómo configurar IBM MQ para aprovechar el soporte de COM+.