Gestion des transactions locales
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_autocommit() 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.
La détection des limites d'une transaction en se basant que l'API a été améliorée avec PHP 5.5.0 et PECL/mysqlnd_ms 1.5.0 pour couvrir non seulement les appels à mysqli_autocommit() mais aussi à mysqli_begin(), mysqli_commit() et mysqli_rollback().
Document créé le 30/01/2003, dernière modification le 26/10/2018
Source du document imprimé : https://www.gaudry.be/php-rf-mysqlnd-ms.transaction.html
L'infobrol est un site personnel dont le contenu n'engage que moi. Le texte est mis à disposition sous licence CreativeCommons(BY-NC-SA). Plus d'info sur les conditions d'utilisation et sur l'auteur.
Références
Ces références et liens indiquent des documents consultés lors de la rédaction de cette page, ou qui peuvent apporter un complément d'information, mais les auteurs de ces sources ne peuvent être tenus responsables du contenu de cette page.
L'auteur de ce site est seul responsable de la manière dont sont présentés ici les différents concepts, et des libertés qui sont prises avec les ouvrages de référence. N'oubliez pas que vous devez croiser les informations de sources multiples afin de diminuer les risques d'erreurs.
