2. Administrando transacciones 2PC en las Mule Applications


En este punto te explicaré como aplicar las transacciones con consistencia fuerte llamadas Two Phase Commit.

 

Tipos de Transacciones en Mule

Tipo de Transacción Descripción Recursos Conectores Soportados Rendimiento
Local (Un único recurso) Operaciones a un solo recurso, como una base de datos. 1 JMS, VM, JDBC Alto
Global (XA) Operaciones entre múltiples recursos compatibles con XA. >1 JMS, VM, JDBC (XA) Comparativamente más lento que local, pero mantiene ACID en múltiples recursos
  • Transacción Local: Imagina que tienes una sola base de datos. Una transacción local se refiere a operaciones que afectan únicamente a este recurso. Si algo falla, todo se revierte en esa única base de datos.
  • Transacción Global (XA): Ahora piensa que tu flujo interactúa con múltiples sistemas, como dos bases de datos o una base de datos y un servidor JMS. Aquí es donde necesitas una transacción global XA que puede manejar múltiples recursos a la vez.

Manejo de Transacciones con Bitronix:

  • Bitronix es un gestor de transacciones que soporta XA en Mule, y para usarlo, lo declaras en la configuración global de tu aplicación Mule.

Operaciones de Conectores que Soportan Transacciones

En Mule, ciertos conectores están configurados para soportar transacciones.

  • JMS: Publish, Consume, On New Message.
  • VM: Publish, Consume, Listener, Publish Consume.
  • Database: Todas las operaciones.

Todo el procesamiento de mensajes se realiza en un único hilo para mantener la integridad de la transacción.

 

Comenzando y Finalizando Transacciones

Acción Descripción
Demarcar Inicio Usar Try o un conector transaccional como fuente de eventos (DB, JMS, VM).
Demarcar Fin Commit automático al finalizar el flujo o scope de Try, o rollback en caso de error. La imagen anterior puedes ver un ejemplo.

Participación en Transacciones

Los conectores pueden comportarse de diferentes maneras en una transacción, desde nunca participar hasta unirse siempre a una transacción en curso.

Acción Soporte del Procesador Descripción
NONE JMS, VM, DB (Solo listeners) Nunca participa en TX, ignora TX en curso
INDIFFERENT Try scope Nunca participa en TX, ignora TX en curso
ALWAYS_BEGIN JMS, VM, DB (Solo listeners) y Try scope Siempre comienza una nueva TX, lanza excepción si hay TX en curso
ALWAYS_JOIN JMS, VM, DB (Solo listeners) Siempre participa en TX en curso, lanza excepción si no hay TX
BEGIN_OR_JOIN Try scope Participa en TX en curso o comienza una nueva si no hay TX
JOIN_IF_POSSIBLE JMS, VM, DB (Solo listeners) Participa en TX en curso, no comienza una nueva si no hay TX

Conclusión

Para tu rol de Mulesoft Architect, la diferencia crítica entre una transacción local y una XA es que la primera se limita a un solo recurso, mientras que la XA abarca varios. Esto es vital cuando tus flujos necesitan interactuar de forma segura y consistente con múltiples sistemas externos.

Deja un comentario

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