Comme pour tout ce qui concerne les performances, la réponse est :cela dépend. Plus précisément, cela dépend exactement de la façon dont vous utilisez le pilote.
Le coût de l'interaction transactionnelle avec une base de données se divise grosso modo en :surcharge de complexité du code, surcharge de communication, traitement sql et E/S disque.
Le surcoût de communication diffère quelque peu entre les cas XA et non-XA. Toutes choses étant égales par ailleurs, une transaction XA entraîne un peu plus de coût ici car elle nécessite plus d'allers-retours vers la base de données. Pour une transaction non-XA en mode commit manuel, le coût est d'au moins deux appels :la ou les opération(s) sql et le commit. Dans le cas de XA, il s'agit de début, opération(s) sql, fin, préparation et validation. Pour votre cas d'utilisation spécifique qui sera automatiquement optimisé pour démarrer, opération(s) sql, terminer, préparer. Tous les appels n'ont pas le même coût :les données déplacées dans le jeu de résultats dominent généralement. Sur un réseau local, le coût des allers-retours supplémentaires n'est généralement pas significatif.
Notez cependant qu'il y a quelques pièges intéressants qui guettent les imprudents. Par exemple, certains pilotes ne prennent pas en charge la mise en cache des instructions préparées en mode XA, ce qui signifie que l'utilisation de XA entraîne la surcharge supplémentaire de la réanalyse du SQL à chaque appel, ou vous oblige à utiliser un pool d'instructions séparé au-dessus du pilote. En ce qui concerne les pools, la mise en pool correcte des connexions XA est un peu plus complexe que la mise en pool des connexions non-XA, donc en fonction de l'implémentation du pool de connexions, vous pouvez également y voir un léger coup. Certains frameworks ORM sont particulièrement vulnérables à la surcharge de regroupement de connexions s'ils utilisent une libération de connexion agressive et réacquièrent dans la portée de la transaction. Si possible, configurez pour saisir et maintenir une connexion pendant toute la durée de vie du tx au lieu de toucher le pool plusieurs fois.
Avec la mise en garde mentionnée précédemment concernant la mise en cache des instructions préparées, il n'y a pas de différence matérielle dans le coût de la gestion sql entre XA et non-XA tx. Il existe cependant une petite différence dans l'utilisation des ressources sur le serveur de base de données :dans certains cas, il peut être possible pour le serveur de libérer des ressources plus tôt dans le cas non-XA. Cependant, les transactions sont normalement suffisamment courtes pour que cela ne soit pas une considération importante.
Considérons maintenant la surcharge d'E/S disque. Ici, nous sommes concernés par les E/S occasionnées par le protocole XA plutôt que par le SQL utilisé pour la logique métier, car ce dernier est inchangé dans les deux cas. Pour les transactions en lecture seule, la situation est simple :un gestionnaire de base de données et de tx sensé n'effectuera aucune écriture dans le journal, il n'y a donc pas de surcharge. Pour les cas d'écriture, il en va de même lorsque la base de données est la seule ressource impliquée, en raison de l'optimisation de validation en une phase de XA. Pour le cas 2PC, chaque serveur de base de données ou autre gestionnaire de ressources a besoin de deux écritures sur disque au lieu de celle utilisée dans les cas non-XA, et le gestionnaire tx en a également besoin de deux. Grâce à la lenteur du stockage sur disque, il s'agit de la principale source de surcharge de performances dans XA par rapport à non-XA.
Plusieurs paragraphes en arrière, j'ai mentionné la complexité du code. XA nécessite un peu plus d'exécution de code que non-XA. Dans la plupart des cas, la complexité est enfouie dans le gestionnaire de transactions, bien que vous puissiez bien sûr piloter XA directement si vous préférez. Le coût est pour la plupart insignifiant, sous réserve des mises en garde déjà mentionnées. Sauf si vous utilisez un gestionnaire de transactions particulièrement médiocre, auquel cas vous pourriez avoir un problème. Le cas en lecture seule est particulièrement intéressant :les fournisseurs de gestionnaires de transactions concentrent généralement leurs efforts d'optimisation sur le code d'E/S du disque, tandis que les conflits de verrouillage sont un problème plus important pour les cas d'utilisation en lecture seule, en particulier sur les systèmes hautement concurrents.
Notez également que la complexité du code dans le gestionnaire tx est en quelque sorte un faux-fuyant dans les architectures comportant un serveur d'applications ou un autre fournisseur de gestionnaire de transactions standard, car ceux-ci utilisent généralement à peu près le même code pour la coordination des transactions XA et non-XA. Dans les cas non-XA, pour passer complètement à côté du gestionnaire tx, vous devez généralement dire au serveur d'application/framework de traiter la connexion comme non transactionnelle, puis piloter la validation directement à l'aide de JDBC.
Ainsi, le résumé est :Le coût de vos requêtes SQL va dominer le temps de transaction en lecture seule, quel que soit le choix XA/non-XA , à moins que vous ne ratiez quelque chose dans la configuration ou que vous fassiez des opérations sql particulièrement triviales dans chaque tx, ce dernier étant un signe que votre logique métier pourrait probablement utiliser une restructuration pour modifier le ratio entre les frais généraux de gestion tx et la logique métier dans chaque tx.
Pour les cas en lecture seule, le conseil habituel agnostique du protocole de transaction s'applique donc :considérez un cache de second niveau de niveau transactionnel dans une solution ORM plutôt que de frapper la base de données à chaque fois. À défaut, réglez le sql, puis augmentez le cache de la mémoire tampon de la base de données jusqu'à ce que vous voyiez un taux de réussite de 90 % ou que vous maximisiez les emplacements de RAM du serveur, selon la première éventualité. Ne vous inquiétez de XA par rapport à non-XA qu'une fois que vous avez fait cela et trouvé que les choses sont encore trop lentes.
