2Phase Commit

Hoy en día casi todas las aplicaciones utilizan bases de datos para almacenar y transaccionar la información, sin embargo casi todas las aplicaciones tiene como origen de datos una sola base de datos centralizada, en donde guardan toda la información, actualizan o borran, para lo cual una sola transacción garantiza que todos los cambios que realicemos se apliquen de forma atómica.

2Phase commit
Fig. 1: En la figura se puede apreciar como la aplicación abre una transacción única, de esta forma todos los cambios serán aplicados de forma atómica.

 

Sin embargo existen casos concretos en los que es necesario actualizar mas de una base datos en una sola operación, un caso muy tipo es SOA, debido a que es común la necesidad de transaccionar con mas de una base de datos al mismo tiempo.

2Phase commit
Fig. 2: La imagen muestra como una aplicación realiza cambios en dos bases de datos a la vez, pero los realiza en dos transacciones independientes.

Este tipo de transacciones pueden ser delicadas debido a que si hacemos commit en la primera, pero la segunda falla, tendremos un problema de integridad, ya que la primera base de datos habrá aplicados los cambios en el commit y la segunda base de datos realizara un RollBack, deshaciendo todos los cambios.

2Phase commit
Fig. 3: En la imagen se muestra como una transacción fue exitosa y la otra no, esto desde luego provoca que perdamos la integridad de los datos.

2Phase Commit o Commit de dos faces.

Para resolver el problema que acabamos de ver, es necesario utilizar transacciones distribuidas con un Commit de dos faces.

El 2Phase Commit o Commit de dos faces se diferencia de un commit normal en que este engloba un una sola transacción los cambios realizados en dos o mas base de datos a la vez(XA Transaction). Para realizar esto, cada manejador de base de datos abrirá una transaccion de forma separada. El coordinador de la transacción les solicitara a todos los manejadores de base de datos que se preparen para el commit( Paso 1), en este punto cada base de datos esta lista para hacer el commit, Si todos los manejadores pasan por el paso 1 de forma positiva, entonces el coordinador de la transacción solicitara el commit a todos los manejadores. Al final, si todos las base de datos realizan el commit, entonces la transaccion sera exitoso y se habrá realizado una transaccion global.

2Phase commit
Fig. 4: En la imagen podemos apreciar el commit de dos faces, el primer paso del lado izquierdo solicita a los manejadores de base de datos que se preparen para hacer el commit, el paso 2 del lado derecho, solicita a cada manejador que realice el commit.

Otro escenario es cuando alguno de los manejadores falla durante la preparación al commit, por lo cual toda la transacción falla y todos los manejadores dan un Rollback a la transacción.

2Phase commit
Fig. 5: Durante la preparación, una base de datos falla y se aplica un rollback en todas las bases de datos, lo cual provoca un rollback global.

Escenario practico:

Para ilustrar esto de una forma mas practica, hablaremos de un ejemplo concreto donde se podria utilizar una transaccion distribuida o XA Transaction.

Imaginemos que tenemos dos sistemas, el sistema de nomina y el contable, sin embargo requerimos realizar un servicio que nos permita crear un usuario, pero que este usuario sea valido para los dos sistemas, para lo cual el servicio tendrá que escribir en la base de datos de los dos sistemas para crearlos. Desde luego que es importante que si la creación falla en algunos de los dos, el usuario no deberá crearse en ninguno de los dos sistemas.

2Phase commit
Fig. 6:En la imagen podemos ver que el servicio habre una transacción global o XA Transacction y realiza los cambios en ambas bases de datos, luego solicita a los manejadores de base de datos que se preparen para el commit y finalmente se realiza un commit sobre las dos bases de datos.

Acabamos de ver un ejemplo simple donde podemos utilizar un commit de dos faces, sin embargo pueden existir muchos mas escenarios donde sea necesario transaccionar dos o hasta mas base de datos a la vez.

Conclusiones:

Las ventajas que ofrecen el 2Phase commit son muy grandes, ya que nos permite realizar transacciones globales con mas de una bases de datos a la vez, Ya solo dependerá de nosotros utilizarlas sabiamente, ya que en ambientes de integración siempre es mas recomendable utilizar servicios que conexiones directas a la bases de datos de nuestros aplicativos.

4 thoughts to “2Phase Commit”

  1. Hola, Muy claro el concepto y sencillo al parecer.

    Solo me salta una duda, ¿que viene siendo el middleware?

    es un DBMS que se conecta a otras bases de datos? manejando internamente las dos transacciones?

    o es una aplicacion custom? donde manejas las tranasacciones y las mantienes a la espera hasta que todas las demas se hayan realizado correctamente?

    1. El Middleware es el Servidor de aplicaciones como WebLogic, WebSphere,Glassfish, etc.

      Todos los servidores de aplicaciones tiene soporte para transacciones XA por medio de driver XA, y es el servidor de aplicaciones quien se encarga de administrar la transacción, aunque podríamos también hacerlo en una aplicación standalone

  2. Ok muchas gracias, a lo que veo, el middleware es el Servidor de aplicaciones, el cual debe de soportar otro tipo de transaccion, llamado XA, la cual nos sirve para los ambientes distribuidos, soportando un commit a dos faces.

    1. En Java, tenemos los driver XA, los cuales nos permiten crear conexiones a base de datos distribuidas, estas conexiones soportan el 2Phase Commit, Desde luego, la base de datos debe soportarlo y debe proporcionar los driver jdbc adecuados para hacerlo. El Aplication server solo se encarga de administrar las conexiones y las transacciones.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *