La gestion des transactions est impactée en profondeur. Une transaction est une unité logique lancée par le serveur. Cette unité peut se composer d'une ou plusieurs requêtes.
Par défaut, le plugin ne se soucie pas des transactions SQL. Il est donc possible qu'il décide de basculer de connexions dans le cadre de la répartition de charge, et ceci peut arriver au milieu d'une transaction. C'est contre la nature même d'une transaction SQL, le plugin n'est donc, par défaut, pas au courant des transactions.
Toute type de balance de charge MySQL peut être touché entre le début et la fin d'une transaction. Ce peut être de façon explicitie en monitorant les appels API ou en utilisant des astuces SQL. L'API de monitorage nécessite PHP 5.4.0 ou supérieur. Le plugin, tout comme n'importe quel répartiteur de charge MySQL, ne peut pas détecter les limites d'une transaction en se basant sur le protocole client serveur de MySQL. Aussi, une transparence totale d'une transaction avec un répartiteur de charge n'est pas possible. L'option la moins intrusive est l'API de monitorage, qui nécessite très peu de modifications de l'application.
Vous trouverez des exemples d'utilisation d'astuces SQL ou de l'API de monitorage dans la section des exemples. Les détails de l'API de monitorage, qui rend les transactions au niveau du plugin sûres, sont décrits ci-dessous.
Depuis PHP 5.4.0, la bibliothèque mysqlnd autorise ce plugin à surcharger l'appel API C set_autocommit(), afin de détecter le statut du mode autocommit.
Les extensions PHP pour MySQL effectuent une requête (comme SET AUTOCOMMIT=0|1), ou utilisent l'appel mysqlnd set_autcommit() pour contrôler le statut de l'autocommit. Si une extension utilise set_autocommit(), le plugin sera au courant des transactions, ce n'est pas le cas si du SQL est utilisé. L'appel set_autocommit() est utilisé par mysqli_autocommit() et PDO::setAttribute(PDO::ATTR_AUTOCOMMIT).
L'option de configuration du plugin trx_stickiness=master peut être utilisée pour rendre le plugin sensible aux transactions. Grâce à ça, le plugin arrête la répartition de charge si l'autocommit est désactivé, et la réactive dans le cas contraire.
Une application qui ne veut pas utiliser les astuces SQL pour les transactions mais souhaite utiliser l'API de monitorage pour éviter les modifications applicatifs doit s'assurer que la configuration autocommit est bien modifiée que via les appels API listés.