11.9.5. Limitations dans le processus de recouvrement XA

Si le serveur JBoss EAP échoue après qu'une méthode de validation XAResource réussisse et validifie la transaction, mais avant que le coordinateur puisse mettre le journal à jour, vous verrez sans doute le message suivant apparaître dans le journal quand vous démarrerez le serveur à nouveau :

ARJUNA016037: Could not find new XAResource to use for recovering non-serializable XAResource XAResourceRecord

C'est parce que lors de la restauration, le gestionnaire de transactions de JBoss (Jboss Transaction Manager) voit les participants à la transaction dans le journal et tente la validation à nouveau. Ensuite, le gestionnaire de transactions de JBoss suppose que les ressources sont validées et ne tente plus de valider à nouveau. Dans ce cas, il est possible d'ignorer cet avertissement car la transaction est validée et il n'y a aucune perte de données.

Pour éviter cet avertissement, définir la valeur de la propriété com.arjuna.ats.jta.xaAssumeRecoveryComplete à true . Cette propriété est vérifiée à chaque fois qu'une nouvelle instance de XAResource ne peut pas être trouvée parmi les XAResourceRecovery enregistrées. Si défini sur true, le recouvrement assume que les tentatives précédentes ont réussi, et l'instance peut être supprimée du journal sans besoin de nouvelle tentative. Cette propriété doit être utilisée avec soin car elle est globale et si elle est utilisée par de façon erronée, on se retrouve avec des instances XAResource restantes non validées.

Si le serveur JBoss EAP se plante suite à un appel de méthode XAResource prepare(), tous les participants à XAResources sont verrouillés dans l'état « prepared » et y demeurent lors du redémarrage du serveur. La transaction n'est pas restaurée et les ressources restent verrouillées jusqu'à ce que l'opération arrive à expiration ou qu'un DBA restaure les ressources et efface les transactions du journal manuellement.

Quand le serveur est sous charge intensive, le journal du serveur peut contenir les messages d'avertissement suivants, suivis d'un stackstace :

ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_NOTA: javax.transaction.xa.XAException

Sous forte charge, le temps de traitement pris par une transaction peut chevaucher le calendrier d'activité de la procédure de restauration périodique. Le processus de restauration périodique détecte la transaction en cours d'exécution et essaie d'initier une restauration, mais en fait, la transaction se poursuit jusqu'à la fin. Au moment où le processus de restauration périodique tente mais échoue à la restauration, il enregistre l'échec de restauration dans le journal de serveur. La cause sous-jacente de cette question sera abordée dans une prochaine version, mais en attendant, une solution de contournement est disponible.

Augmenter l'intervalle entre les deux phases du processus de restauration en définissant la propriété com.arjuna.ats.jta.orphanSafetyInterval sur une valeur supérieure à la valeur par défaut de 10 000 millisecondes. Une valeur de 40 000 millisecondes est recommandée. Veuillez noter que cela ne résout pas le problème, au contraire, cela diminue la probabilité qu'il se produira et que le message d'avertissement s'affichera dans le journal.