En los primeros días de la computación, no había necesidad de transacciones distribuidas. A medida que aumenta el número de aplicaciones, la sincronización de los datos se convierte en un tema importante. Las empresas pagaron mucho para mantener sistemas sincronizados en términos de flujo de datos. Como resultado, surgió el protocolo de confirmación de 2 fases denominado XA(Arquitectura extendida). Este protocolo proporciona propiedades de tipo ÁCIDO para el procesamiento de transacciones globales. A lo largo de este artículo, intentaré explicar los detalles de las transacciones XA y el uso de las transacciones XA en Spring framework.
el protocolo de compromiso de 2 fases es un protocolo de compromiso atómico para sistemas distribuidos. Este protocolo, como su nombre indica consta de dos fases. La primera es la fase de solicitud de confirmación en la que el administrador de transacciones coordina todos los recursos de transacción a confirmar o abortar. En la fase de confirmación, el administrador de transacciones decide finalizar la operación confirmando o cancelando de acuerdo con los votos del recurso de cada transacción. A continuación, pasaremos a los detalles de implementación del protocolo 2PC.
* Consulte aquí los recursos de interoperabilidad de Java+. NET a través de 2 PIEZAS.
Las transacciones XA necesitan un id de transacción global y un id de transacción local(xid) para cada recurso XA. Cada recurso XA se enlista al Administrador XA mediante el método start(xid). Este método indica que el recurso XA está involucrado en la transacción(esté listo para las operaciones). Después de eso, la primera fase del protocolo 2PC se realiza llamando al método prepare(xid). Este método solicita el voto OK o ABORTAR del recurso XA. Después de recibir el voto de cada Recurso XA, el Administrador de XA decide ejecutar una operación de confirmación(xid) si todos los Recursos XA envían OK o decide ejecutar una reversión(xid) si un recurso XA envía ABORTAR. Finalmente, se llama al método end(xid) para cada recurso XA que indica que la transacción se ha completado. Mira la figura para entender mejor. A medida que construimos un fondo en la implementación de transacciones XA, a continuación profundizaremos y veremos los tipos de fallas y las posibles soluciones.
Las fallas pueden ocurrir en cualquier momento debido a la pérdida de la red, la caída de la máquina y algún error del administrador. En la transacción XA, clasificaremos estos fallos de acuerdo con las fases en las que se producen. La primera fase de falla es antes de que se inicie el protocolo. Este es un simple fallo que el sistema no necesita revertir ni ningún tipo de operación. Simplemente no hacemos la operación en ese momento en particular. El segundo tipo de fallo puede ocurrir en la fase de preparación(solicitud de confirmación), que puede manejarse fácilmente mediante reversiones utilizando políticas de tiempo de espera. Por último, pero no menos importante, están los fallos de fase de confirmación que pueden ocurrir debido a retrocesos incompletos y a cualquier problema en la cadena. En todas estas situaciones anteriores, el administrador de transacciones intenta recuperar el problema. A continuación veremos cómo transaction manager intenta superar los fallos.
Para la recuperación, el administrador de transacciones llama al método de recuperación de cada recurso XA. Los recursos XA rastrean los registros e intentan reconstruir su estado más reciente. El Administrador de transacciones llama a las operaciones de reversión necesarias y se cumple la misión. Este proceso puede parecer un camino feliz, pero hay muchas situaciones excepcionales en las que los registros son problemáticos, como estar dañados. En este tipo de situaciones, transaction manager sigue algunas heurísticas para resolver el problema. Además, el proceso de recuperación depende de los registros de escritura anticipada en los que se escriben los registros de operación antes de aplicar. Para problemas de rendimiento, estos registros se escriben en su propio formato (no se utiliza ninguna serialización) y el sistema debería mejor agruparlos si es posible. A continuación, vamos a la parte divertida, que es el soporte de transacciones XA de Spring Framework.
Spring framework proporciona un amplio entorno para desarrollar aplicaciones web y autónomas. Al igual que otras utilidades que proporciona, Spring también admite transacciones XA. Sin embargo, este soporte no es una implementación nativa y requiere hibernación, contenedor web o un marco que proporcione Administración de transacciones XA. Spring tiene JtaTransactionManager que proporciona utilidades de administración de transacciones y oculta los detalles. De esta manera, podemos tener gestión de transacciones para múltiples fuentes de datos que se actualizan simultáneamente. Cuando se trata de usar la gestión de transacciones XA, el soporte de contenedores web y de hibernación para transacciones XA está bien documentado, no es necesario mencionarlo. Sin embargo, trabajar con un marco que proporciona transacciones XA puede ser confuso. Por lo tanto, continuaré este post presentando Bitronix Transaction Manager.
Bitronix se configura fácilmente y proporciona un buen soporte para la administración de transacciones. No se usa comúnmente en aplicaciones independientes, pero intentaré dar la configuración para aplicaciones independientes de la siguiente manera.
<bean factory-method="getConfiguration" class="bitronix.tm.TransactionManagerServices"> <!--Disabling Jmx avoids registering JMX Beans to any container--> <property name="disableJmx" value="true" /></bean><bean factory-method="getTransactionManager" class="bitronix.tm.TransactionManagerServices" depends-on="bitronixTMConfig" destroy-method="shutdown"/><bean class="org.springframework.transaction.jta.JtaTransactionManager"> <property name="transactionManager" ref="bitronixTM" /> <property name="userTransaction" ref="bitronixTM" /> <property name="allowCustomIsolationLevels" value="true" /></bean>
ahora podemos tener múltiples fuentes de datos que se pueden configurar de la siguiente manera. Cada fuente de datos debe tener una propiedad UniqueName que sea única. A continuación, la configuración es para Oracle, otras bases de datos pueden tener configuraciones diferentes. Para cualquier otro detalle, puede consultar el sitio web de Bitronix.
<bean class="bitronix.tm.resource.jdbc.PoolingDataSource" init-method="init" destroy-method="close"> <property name="uniqueName" value="xaDataSource" /> <property name="minPoolSize" value="1" /> <property name="maxPoolSize" value="4" /> <property name="testQuery" value="SELECT 1 FROM dual" /> <property name="driverProperties"> <props> <prop key="URL">jdbc:oracle:thin:@10.6.86.24:1521:test</prop> <prop key="user">test</prop> <prop key="password">test</prop> </props> </property> <property name="className" value="oracle.jdbc.xa.client.OracleXADataSource" /> <property name="allowLocalTransactions" value="true" /></bean>
En resumen, hemos intentado explicar qué son las transacciones XA, los protocolos subyacentes y la integración de Gestión de transacciones de Bitronix con Spring en una aplicación independiente. Para ampliar, XA Transactions proporciona la modificación de diferentes fuentes de datos al mismo tiempo. Además, las transacciones XA son compatibles con contenedores web o entornos de hibernación similares. Sin embargo, es posible que necesitemos integrar la administración de transacciones a una aplicación independiente en la que debemos configurar el administrador de transacciones. En consecuencia, XA transaction proporciona operaciones consistentes en múltiples fuentes de datos y las empresas las utilizan.
* Notas del Curador y recursos adicionales