Dans les premiers jours de l’informatique, il n’y avait pas besoin de transactions distribuées. À mesure que le nombre d’applications augmentait, la synchronisation des données devenait un problème important. Les entreprises ont payé beaucoup pour maintenir des systèmes synchronisés en termes de flux de données. En conséquence, le protocole de validation en 2 phases appelé XA (architecture étendue) est apparu. Ce protocole fournit des propriétés de type ACIDE pour le traitement global des transactions. Tout au long de cet article, je vais essayer d’expliquer les détails des transactions XA et l’utilisation des transactions XA dans Spring framework.
2 phase commit protocol est un protocole d’engagement atomique pour les systèmes distribués. Ce protocole, comme son nom l’indique, se compose de deux phases. La première est la phase de requête de validation dans laquelle le gestionnaire de transactions coordonne toutes les ressources de transaction à valider ou à abandonner. Lors de la phase de validation, le gestionnaire de transactions décide de finaliser l’opération en validant ou en abandonnant en fonction des votes de chaque ressource de transaction. Nous passerons ensuite aux détails de mise en œuvre du protocole 2PC.
* Voir ici pour les ressources sur l’interopérabilité Java + .NET via 2PC.Les transactions XA
nécessitent un id de transaction global et un id de transaction local (xid) pour chaque ressource XA. Chaque ressource XA est enrôlée dans XA Manager par la méthode start (xid). Cette méthode indique que la ressource XA est impliquée dans la transaction (soyez prêt pour les opérations). Après cela, la première phase du protocole 2PC est réalisée en appelant la méthode prepare (xid). Cette méthode demande le vote OK ou ABORT de la ressource XA. Après avoir reçu un vote de chacune des Ressources XA, XA Manager décide d’exécuter une opération de validation (xid) si toutes les Ressources XA envoient OK ou décide d’exécuter une restauration (xid) si une ressource XA envoie un ABANDON. Enfin, la méthode end (xid) est appelée pour chacune des ressources XA indiquant que la transaction est terminée. Regardez la figure pour mieux comprendre. Au fur et à mesure que nous élaborons un contexte dans la mise en œuvre des transactions XA, nous irons plus loin et verrons les types d’échecs et les solutions possibles.
Des pannes peuvent survenir à tout moment en raison d’une perte de réseau, d’une panne de machine et d’une erreur d’administrateur. Dans la transaction XA, nous classerons ces échecs en fonction des phases où ils se produisent. La première phase d’échec est avant le démarrage du protocole. Il s’agit d’une simple défaillance que le système n’a pas besoin de restaurer ou de toute sorte d’opération. Nous ne faisons tout simplement pas l’opération pour ce moment particulier. Un deuxième type d’échec peut se produire lors de la phase de préparation (requête de validation) qui peut être facilement gérée par des rollbacks à l’aide de stratégies de délai d’attente. Enfin, les échecs de phase de validation peuvent survenir en raison de rollbacks incomplets et de tout problème de chaîne. Dans toutes ces situations ci-dessus, le gestionnaire de transactions essaie de récupérer le problème. Nous verrons ensuite comment transaction manager tente de surmonter les échecs.
Pour la récupération, le gestionnaire de transactions appelle la méthode de récupération de chaque ressource XA. Les ressources XA tracent les journaux et tentent de reconstruire sa dernière condition. Le gestionnaire des transactions appelle les opérations de restauration nécessaires et la mission est accomplie. Ce processus peut sembler être un chemin heureux, mais il y a beaucoup de situations exceptionnelles où les journaux sont problématiques comme être corrompus. Dans ce genre de situations, transaction manager suit certaines heuristiques pour résoudre le problème. De plus, le processus de récupération dépend des journaux d’écriture anticipée où vous écrivez des journaux d’opérations avant de les appliquer. Pour les problèmes de performances, ces journaux sont écrits dans leur propre format (sans utiliser de sérialisation) et le système devrait mieux les regrouper si possible. Nous passons ensuite à la partie amusante qui est le support des transactions XA par Spring framework.
Spring framework fournit un environnement étendu pour développer des applications web et autonomes. Comme les autres utilitaires qu’il fournit, les transactions XA sont également prises en charge par Spring. Cependant, ce support n’est pas une implémentation native et nécessite une mise en veille prolongée, un conteneur Web ou un framework qui fournit une gestion des transactions XA. Spring dispose de JtaTransactionManager qui fournit des utilitaires de gestion des transactions et masque les détails. De cette façon, nous pouvons avoir une gestion des transactions pour plusieurs sources de données qui sont mises à jour simultanément. Lorsqu’il s’agit d’utiliser la gestion des transactions XA, la prise en charge des conteneurs hibernate et Web pour les transactions XA est bien documentée et n’a pas besoin d’être mentionnée. Cependant, travailler avec un cadre qui fournit des transactions XA peut être déroutant. Ainsi, je vais continuer cet article en présentant Bitronix Transaction Manager.
Bitronix est facilement configuré tout en offrant un bon support pour la gestion des transactions. Il n’est pas couramment utilisé dans les applications autonomes, mais je vais essayer de donner la configuration pour les applications autonomes comme suit.
<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>
Nous pouvons maintenant avoir plusieurs sources de données qui peuvent être configurées comme suit. Chaque source de données doit avoir une propriété uniqueName unique. La configuration ci-dessous est pour Oracle, d’autres bases de données peuvent avoir des configurations différentes. Pour tout autre détail, vous pouvez consulter le site 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>
Pour résumer, nous avons essayé d’expliquer ce qu’est une transaction XA, les protocoles sous-jacents et l’intégration de la gestion des transactions Bitronix avec Spring dans une application autonome. Pour étendre, les transactions XA permettent de modifier différentes sources de données en même temps. De plus, les transactions XA sont prises en charge par des conteneurs Web ou des frameworks de type hibernate. Néanmoins, nous devrons peut-être intégrer la gestion des transactions à une application autonome dans laquelle nous devons configurer transaction manager. En conséquence, XA transaction fournit des opérations cohérentes sur plusieurs sources de données et les entreprises les utilisent.
* Notes du conservateur et ressources supplémentaires