X/Abrir XA
Para el procesamiento de transacciones en informática, el estándar X/Open XA (abreviatura de "eXtended Architecture") es una especificación publicada en 1991 por X/Open (que luego se fusionó con The Open Group) para el procesamiento de transacciones distribuidas (DTP).
Objetivos
El objetivo de XA es garantizar la atomicidad en las "transacciones globales" que se ejecutan a través de componentes heterogéneos. Una transacción es una unidad de trabajo como transferir dinero de una persona a otra. Las transacciones distribuidas actualizan múltiples almacenes de datos (como bases de datos, servidores de aplicaciones, colas de mensajes, cachés transaccionales, etc.) Para garantizar la integridad, XA utiliza una confirmación de dos fases (2PC) para garantizar que todos los cambios de una transacción entrar en vigor (confirmar) o no (revertir), es decir, atómicamente.
Arquitectura
Específicamente, XA describe la interfaz entre un administrador de transacciones global y una aplicación específica. Una aplicación que quiere utilizar XA recurre a un administrador de transacciones XA mediante una biblioteca o un servicio independiente. El administrador de transacciones rastrea a los participantes en la transacción (es decir, los distintos almacenes de datos en los que escribe la aplicación) y trabaja con ellos para llevar a cabo la confirmación de dos fases. En otras palabras, el administrador de transacciones XA está separado de las interacciones de una aplicación con los servidores. XA mantiene un registro de sus decisiones de confirmación o reversión, que puede utilizar para recuperarse en caso de una interrupción del sistema.
Muchos proveedores de software admiten XA (lo que significa que el software puede participar en transacciones XA), incluida una variedad de bases de datos relacionales y corredores de mensajes.
Ventajas y desventajas
Dado que XA utiliza confirmación de dos fases, las ventajas y desventajas de ese protocolo generalmente se aplican a XA. La principal ventaja es que XA (usando 2PC) permite una transacción atómica a través de múltiples tecnologías heterogéneas (por ejemplo, una sola transacción podría abarcar múltiples bases de datos de diferentes proveedores, así como un servidor de correo electrónico y un intermediario de mensajes), mientras que las transacciones de bases de datos tradicionales se limitan a una base de datos única.
La principal desventaja es que 2PC es un protocolo de bloqueo: los otros servidores deben esperar a que el administrador de transacciones emita una decisión sobre si confirmar o cancelar cada transacción. Si el administrador de transacciones se desconecta mientras las transacciones esperan su decisión final, quedarán bloqueadas y mantendrán los bloqueos de su base de datos hasta que el administrador de transacciones vuelva a conectarse y emita su decisión. Esta retención prolongada de bloqueos puede resultar perjudicial para otras aplicaciones que utilizan las mismas bases de datos.
Además, si el administrador de transacciones falla y su registro de decisiones no se puede recuperar (por ejemplo, debido a un error en la forma en que se registraron las decisiones o debido a corrupción de datos en el servidor), puede ser necesaria una intervención manual. Muchas implementaciones de XA proporcionan una "escotilla de escape" para que las transacciones decidan de forma independiente si se confirman o abortan (sin esperar a recibir noticias del administrador de transacciones), pero esto corre el riesgo de violar la garantía de atomicidad y, por lo tanto, está reservado para emergencias.
Especificación
La especificación XA describe lo que debe hacer un administrador de recursos para admitir el acceso transaccional. Se dice que los administradores de recursos que siguen esta especificación son compatibles con XA.
La especificación XA se basó en una interfaz utilizada en el sistema Tuxedo desarrollado en la década de 1980, pero adoptada por varios sistemas desde entonces.