In the early days of computing, there was no need for distributed transactions. À medida que o número de aplicações aumenta, a sincronização dos dados torna-se uma questão importante. As empresas pagaram muito para manter sistemas sincronizados em termos de fluxo de dados. Como resultado, o protocolo de commit de 2 fases referido como XA(arquitetura estendida) surgiu. Este protocolo fornece propriedades ácido-like para processamento de transação global. Ao longo deste artigo, vou tentar explicar detalhes de transações XA e uso de transações XA no marco da Primavera.
2 phase commit protocol is an atomic commitment protocol for distributed systems. Este protocolo, tal como o seu nome implica, consiste em duas fases. O primeiro é a fase de commit-request na qual o Gerenciador de transações coordena todos os recursos de transação para commit ou abortar. Na fase de commit, o Gerenciador de transações decide finalizar a operação, cometendo ou abortando de acordo com os votos de cada recurso de transação. Em seguida, passaremos aos detalhes de implementação do protocolo 2PC.
* veja aqui os recursos na interoperabilidade Java+. NET através do 2PC.
as transacções XA necessitam de um id de transacção global e de um id de transacção local(xid) para cada recurso XA. Cada recurso XA é recrutado para o Gestor XA pelo método start(xid). Este método diz que o recurso XA está sendo envolvido na transação(esteja pronto para as operações). Depois disso, a primeira fase do protocolo 2PC é realizada chamando o método prepare(xid). Este método pede OK ou abortar a votação do recurso XA. Depois de receber o voto de cada recurso do XA, o gestor do XA decide executar uma operação de commit(xid) se todos os recursos do XA enviarem OK ou decidirem executar um rollback(xid) se um recurso do XA enviar abortar. Finalmente, o método end(xid) é chamado para cada recurso XA dizendo que a transação está concluída. Olhe para a figura para entender melhor. À medida que construirmos um fundo na implementação de transação XA, vamos em seguida ir mais fundo e ver tipos de falhas e possíveis soluções.
falhas podem ocorrer a qualquer momento devido à perda de rede, queda de máquina e algum erro de administrador. Na transação XA, vamos categorizar essas falhas de acordo com as fases que ocorrem. A primeira fase de falha é antes do protocolo ser iniciado. Esta é uma falha simples que o sistema não precisa para rollback ou qualquer tipo de operação. Não fazemos a operação nesse momento. O segundo tipo de falha pode ocorrer na fase de preparação(commit-request), que pode ser facilmente tratado por rollbacks usando Políticas de tempo-limite. Por último, mas não menos importante, são falhas de fase de commit que podem ocorrer devido a rollbacks incompletos e qualquer problema na cadeia. Em todas estas situações acima, gerente de transação tenta recuperar o problema. Veremos em seguida como o Gerenciador de transações tenta superar falhas.
para recuperação, o Gestor de operações chama método de recuperação de cada recurso XA. Os recursos da XA localizam os logs e tentam reconstruir a sua última condição. O Gestor de operações chama as operações de rollback necessárias e a missão é cumprida. Este processo pode parecer ser Caminho feliz, mas há um monte de situações excepcionais em que os logs são problemáticos como ser corrompido. Nestes tipos de situações, o gerente de transação segue algumas heurísticas para resolver o problema. Além disso, o processo de recuperação depende dos logs write-ahead onde você escreve logs de operação antes de aplicar. Para problemas de desempenho estes logs são escritos em seu próprio formato(não usando qualquer serialização) e sistema deve melhor lote-los, se possível. Em seguida, vamos para a parte divertida, que é o Suporte de transação XA pelo framework Spring.
o Spring framework fornece um ambiente extenso para desenvolver aplicações web e stand alone. Como outros utilitários que ele fornece, as transações XA também são suportados pela primavera. No entanto, este suporte não é uma implementação nativa e requer hibernar, container web ou um framework que fornece gerenciamento de transações XA. Spring tem JtaTransactionManager que fornece utilitários de gestão de transações e esconde os detalhes. Desta forma, podemos ter gerenciamento de transações para múltiplos recursos de dados que são atualizados simultaneamente. Quando se trata de usar a gestão de transações XA, hibernar e suporte de containers web para transações XA estão bem documentados, não precisa ser mencionado. No entanto, trabalhar com um framework que fornece transações XA pode ser confuso. Assim, eu vou continuar este post, introduzindo Bitronix Transaction Manager.
Bitronix é facilmente configurado, proporcionando um bom suporte para a gestão de transações. Não é comumente usado em aplicações independentes, mas eu vou tentar dar configuração para aplicação independente como segue.
<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>
agora podemos ter várias fontes de dados que podem ser configuradas da seguinte forma. Cada fonte de dados deve ter uma propriedade de nome único que é única. Abaixo a configuração é para Oracle, outras bases de dados podem ter configurações diferentes. Para qualquer outro detalhe, você pode verificar o site 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>
resumindo, nós tentamos explicar o que são transações XA, protocolos subjacentes e integração de gerenciamento de Transações Bitronix com a primavera em uma aplicação independente. Para estender, transações XA fornece modificar diferentes fontes de dados ao mesmo tempo. Além disso, as transações XA são suportadas por contêineres web ou enquadramentos semelhantes hibernados. No entanto, podemos precisar de integrar a gestão de transações a uma aplicação autónoma na qual temos de configurar o Gestor de transações. Consequentemente, a xa transaction fornece operações consistentes em múltiplas fontes de dados e as empresas fazem uso delas.
*notas do curador e recursos adicionais