(PECL mysqlnd_ms < 1.6.0)
mysqlnd_ms_xa_gc — Collecte les données incorrectes issues des transactions XA non terminées en raison d'erreurs sébères
Collecte les données incorrectes issues de transactions XA non terminées.
Le protocole XA est un protocole bloquant. Il existe des cas où les serveurs participants à une transaction globale ne peuvent réaliser les opérations, par exemple, lorsque le coordinateur de transaction s'interrompt de façon innatendu ou se déconnecte. Dans de tel cas, les serveurs MySQL restent en attente d'instruction pour finir la transaction XA en question. En raison du fait que les transactions occupent des ressources, elles doivent toujours être terminées proprement.
Le collecteur de données incorrectes requiert le stockage d'un statut pour tracker les transactions globales. Lorsqu'un client PHP se termine de façon innatendue au milieu d'une transaction, et qu'un nouveau client PHP démarre, alors le collecteur de données incorrectes peut connaître la transaction globale interrompue et la terminer. Si vous ne configurez pas de stockage de statut, le collecteur de données incorrectes ne peut effectuer aucune tâche de nettoyage.
Le stockage de statut doit être sécurisé contre les crash, avoir une haute disponibilité pour survivre à son propre crash. Actuellement, seul MySQL est supporté comme stockage de statut.
Le collecteur de données incorrectes peut aussi être exécuté automatiquement en tâche de fond. Voir la directive de configuration du plugin garbage_collection pour plus de détails.
Note: Expérimental
Cette fonctionalité est actuellement en cours de développement. Il peut y avoir des bogues et/ou des limitations dans les fonctionalités. Ne pas utiliser en environnement de production.
connectionUn gestionnaire de connexion MySQL obtenu depuis une des fonctions de connexion des extensions mysqli, mysql ou PDO_MYSQL.
gtridL'identifiant de transaction globale (gtrid). Si fourni, le collecteur de données incorrectes ne considérera que la transaction. Sinon, le stockage de statut sera analysé à la recherche d'une transaction non terminée.
ignore_max_retriesSi l'on doit ignorer ou non la configuration max_retries du plugin. Si le collecteur de données incorrectes échoue, et que la limite max_retries est atteinte avant de terminer la transaction globale en échec, vous pouvez tenter des exécutions avant de chercher la cause et résoudre le problème manuellement en envoyer des requêtes SQL appropriées aux participants. Le fait de définir ce paramètre a le même effet que de définir temporairement la configuration max_retries = 0.
Retourne TRUE si la transaction globale a été annulée avec succès, FALSE sinon.