Veuillez lire cette réponse ci - dessous , qui détaille les moyens d'atténuer les problèmes décrits ici.
Les mêmes inconvénients existent en utilisant PDO comme avec toute autre interface de base de données PHP qui effectue des connexions persistantes: si votre script se termine de manière inattendue au milieu des opérations de base de données, la prochaine requête qui obtient la connexion restante reprendra là où le script mort s'est arrêté. La connexion est maintenue ouverte au niveau du gestionnaire de processus (Apache pour mod_php, le processus FastCGI actuel si vous utilisez FastCGI, etc.), pas au niveau PHP, et PHP ne dit pas au processus parent de laisser la connexion mourir lorsque le script se termine anormalement.
Si le script mort a verrouillé des tables, ces tables resteront verrouillées jusqu'à ce que la connexion s'éteigne ou que le prochain script qui obtient la connexion déverrouille les tables lui-même.
Si le script mort était au milieu d'une transaction, cela peut bloquer une multitude de tables jusqu'à ce que le minuteur d'interblocage se déclenche, et même dans ce cas, le minuteur de blocage peut tuer la demande la plus récente au lieu de l'ancienne demande à l'origine du problème.
Si le script mort était au milieu d'une transaction, le script suivant qui obtient cette connexion obtient également l'état de la transaction. Il est très possible (en fonction de la conception de votre application) que le prochain script n'essaie jamais de valider la transaction existante, ou s'engage alors qu'il n'aurait pas dû, ou annule quand il n'aurait pas dû.
C'est la partie visible de l'iceberg. Tout cela peut être atténué dans une certaine mesure en essayant toujours de nettoyer après une connexion sale sur chaque requête de script, mais cela peut être pénible en fonction de la base de données. À moins que vous n'ayez identifié la création de connexions à la base de données comme la seule chose qui constitue un goulot d'étranglement dans votre script (cela signifie que vous avez effectué le profilage de code à l'aide de xdebug et / ou xhprof ), vous ne devriez pas considérer les connexions persistantes comme une solution à quoi que ce soit.
De plus, la plupart des bases de données modernes (y compris PostgreSQL) ont leurs propres méthodes préférées pour effectuer le pool de connexions qui ne présentent pas les inconvénients immédiats des connexions persistantes basées sur PHP.
Pour clarifier un point, nous utilisons des connexions persistantes sur mon lieu de travail, mais pas par choix. Nous rencontrions un comportement de connexion étrange , où la connexion initiale de notre serveur d'application à notre serveur de base de données prenait exactement trois secondes, alors qu'elle aurait dû prendre une fraction de fraction de seconde. Nous pensons que c'est un bogue du noyau. Nous avons renoncé à essayer de le dépanner car cela se produisait au hasard et ne pouvait pas être reproduit à la demande, et notre informatique externalisée n'avait pas la capacité concrète de le localiser.
Quoi qu'il en soit, lorsque les gens de l'entrepôt traitent quelques centaines de pièces entrantes et que chaque pièce prend trois secondes et demie au lieu d'une demi-seconde, nous avons dû agir avant qu'ils ne nous kidnappent tous et nous obligent à les aider. Ainsi, nous avons retourné quelques éléments dans notre monstruosité ERP / CRM / CMS locale et avons expérimenté toutes les horreurs des connexions persistantes de première main. Il nous a fallu des semaines pour dépister tous les petits problèmes subtils et les comportements bizarres qui se sont produits apparemment au hasard. Il s'est avéré que ces erreurs fatales une fois par semaine que nos utilisateurs éliminaient avec diligence de notre application laissaient des tables verrouillées, des transactions abandonnées et d'autres états malheureux et bancaux.
Cette histoire sanglante a un point: elle a cassé des choses que nous ne nous attendions jamais à casser, tout cela au nom de la performance. Le compromis n'en valait pas la peine, et nous attendons avec impatience le jour où nous pourrons revenir aux connexions normales sans émeute de la part de nos utilisateurs.