1/07/2004

TRANSACCIONES, ESOS GRANDES DESCONOCIDOS... HASTA AHORA

XA Exposed, Part I: "2PC"


El pasado 5 de Enero (hace dos días) el Spille Blogs publicó la primera parte de su "magnum opus" sobre el Commit en 2 Fases. Me parece interesante comentarlo y resumirlo para "abrir boca" y así lo devoréis mejor.

El artículo comienza con un recordatorio de la integración de sistemas en los 80 y 90, y del problema principal de la agregación de esas "islas de datos" que poblaban (¿poblaban o pueblan?) el mundo empresarial.

Una primera solución al problema de realización de consultas y actualizaciones sobre datos distribuidos en diferentes bases de datos -consistencia, coherencia, etc.- fue el Commit en 2 Fases -2Phase Commit, 2PC o XA- que introduce el concepto de transacción global, y amplía el concepto de transacción obtenido ya hacía tiempo por las bases de datos relacionales a través de sus características ACID (Atomicity, Consistency, Isolation, Durability), a bases de datos distribuidas.


Como bien se apunta en el BLOG, las transacciones distribuidas estuvieron olvidadas por el "informático medio" durante algunos años. Pero ahora, con la necesidad de EAI (Enterprise Application Integration)y EII (Enterprise Information Integration) existente, con arquitecturas asíncronas tipo JMS, se hace vital el contar con un soporte transaccional distribuido... ahora todo el mundo tiene que saber de XA.

El resumen de 2PC lo tomo directamente del blog:
"1. start(Xid) - enlist the resource as part of the transaction
2. end(Xid) - tell the resource that no more transactional work is coming its way
3. prepare(Xid) - prepare for commiting. The resource can respond "OK" or "oh no!". The latter indicates that the whole global transaction should be rolled back.
4. commit(Xid) - Really commit.
", donde Xid es el identificador de la transacción realizada (
XID Javadoc).


Esta frase me hace gracia: "The JTA specification, along with its philosophical parent, the X/Open XA specification[...]". Es como si poco a poco se fueran creando varios tipos de "ingenieros sw": los que leen y entienden y aprecian las especificaciones originales, y los que sólo las aceptan como base de algo más moderno y entendible, y, sobre todo, más práctico. Es como si tuviéramos la frase "La película Matrix, junto con su padre filosófico, La Caverna de Platón[...]" ;)

Un punto bastante conocido de la teoría transaccional local, pero que no deja de ser importante, es que el mayor coste en tiempo de ejecución proviene de lo que en el blog se denomina "disk forcing". Todas las operaciones realizadas han de ser almacenadas en disco para poder ser trazadas ("traceadas"), y de esa manera tengamos tolerancia a fallos (recuperación ante fallos).

Muy interesante, esperaremos a la segunda parte de su trabajo!

No hay comentarios: