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.
Para desarrollar tu habilidad como Mulesoft Developer deja tus datos en el siguiente formulario y te contactaremos: