Bonjour à tous,

Je voudrais tester si une connexion à une base de donnée via PDO est toujours active au milieu d'un script. Comment faire ?

Bizarre comme besoin.

Un SELECT 1 ? (en PDO::query + fetch derrière)

-
Edité par julp 25 octobre 2015 à 11:59:57

@julp

J'aimerais tester si ce que dis le commentaire 1 est vrai :

http://php.net/manual/fr/pdo.connections.php

Car ça me semble tellement.... Ahurissant

Mouais, absolument pas convaincu :

1. il fait volontairement une requête sans en lire le résultat (premier code)
2. il allonge sciemment la durée de ces scripts par un sleep mais est-ce qu'affecter null a vraiment effet immédiat ?

Si j'ai bien compris, il dit quand même qu'à la fin du script, PHP met bien fin à la connexion. C'est lui qui les fait artificiellement durer avec ses sleep. Et les "slow clients" c'est au serveur web en amont de les gérer.

-
Edité par julp 25 octobre 2015 à 14:00:37

PDO ferme automatiquement la connexion à la fin des scripts si tu ne lui dis rien c'est pour ça que le type fait durer son code avec sleep()... le sleep étant après $pdo = null; la connexion devrait être fermée. Hors dans la doc officielle il est dit que $pdo = null; cela ferme la connexion. On ne parle pas des instances mais bien de la connexion, du lien à la base de donnée qui reste établi. J'ai pas encore de grande connaissances donc je peux dire pas mal de conneries mais si tu prends mysqli par exemple la connexion se ferme quand tu lui demandes. Faudrait qu'un membre expérimenté test ça pour vérifier si c'est vrai car je sais pas comment faire pour tester le délire... Y'aurait pas mal de choses à dire sur PDO je trouve..

Voilà j'ai trouvé comment faire et ce que dit le mec est vrai, c'est un truc de malade... Des millions de gens utilisent PDO et croient fermer leur connexion alors que ce n'est pas le cas, ça peut engendrer de gros lags.

Pour ceux qui veulent vérifier il faut utiliser "show processlist;" dans la console MySQL pour voir que ça reste bel et bien connecté en utilisant la méthode officielle. 

Il faut faire comme a dit le type :

<?php 
try {
 $database = new pdo('mysql:host=localhost;dbname=blabla;charset=utf8','root','',array(PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION));
  }
catch (Exception $e) {
 die('Erreur '.$e->getMessage());
}
$query = $database->query('SELECT * FROM cequetuveux');
  
while ($data = $query->fetch()) {
 echo ''.$data['nom'].'<br />';
}
$query->closeCursor(); // Optionnel
$query = null; // Obligatoire si non la connexion ne se ferme pas.
$database = null; // Obligatoire aussi
?>

Si il faut tout mettre à null et vérifier à chaque fois que ça fonctionne bien comment avoir confiance en PDO ?

-
Edité par Konkonbre 25 octobre 2015 à 18:53:03

Effectivement mais il faut relativiser quand même : ce n'est problématique que si le script dure (genre "démon", grosse tâche en CLI) - ce qui ne devrait pas être le cas en web, et où on pensait "dropper" tôt la connexion.

Parce que le PDOStatement (statement) est lié à l'objet PDO (connexion) donc si le statement n'est pas détruit avant, la connexion étant toujours référencé par le statement (PHP gérant sa mémoire/interdépendances via des compteurs), il ne libère pas la mémoire (ce qui comprend la déconnexion) de l'objet PDO comme attendu (son nombre de références n'étant pas nul) ?

• lien statement/connexion 1 ou 2 (entre autres)
• suppression de la référence vers la connexion à la destruction du statement
• ajout d'une référence vers la connexion à l'instanciation (interne) du statement

Si j'interprète bien le résultat de debug_zval_dump, on voit une référence en plus sur l'objet PDO quand on ne NULL (ou peu importe la valeur) pas l'unique statement. (de toute façon, visiblement, le compteur est incrémenté de 1 par statement qui n'est pas préalablement écrasé)

Auquel cas c'est ni plus ni moins le fonctionnement de PHP et pour gérer la mémoire comme tout le monde s'y attendrait, il faudrait :

• que les statements soit associés en retour à la connexion pour qu'à la fermeture de la connexion tout éventuel statement restant soit "détruit" dans le même temps
• ou que les instances PDO/PDOStatement soient vraiment indépendantes, ce qui n'est probablement pas possible pour l'implémentation de certaines fonctionnalités et suivant le pilote (API C derrière - je pense notamment à PDOStatement::rowCount pour par exemple SQLite qui est lié à la connexion et non au statement et même chose pour MySQL quand la requête n'est pas préparée)

De toute façon, même dans un autre langage, avec ce lien entre les classes PDO/PDOStatement, le problème serait le même (en ruby le pdostatement irait marquer l'instance pdo à laquelle il y est lié comme atteignable donc l'objet pdo ne serait pas détruit et, de fait, la connexion perdurerait).

Pour le coup, bonne question, ça change des Q/R type RTFM.

-
Edité par julp 4 avril 2016 à 11:26:37

Ça ne pose pas de problèmes en local ou sur des petits sites en effet, mais qu'en est-il sur un forum par exemple où tu as 1000 membres connectés simultanément et que tu dois faire des requêtes courtes pour soulager le serveur ? Et si sur ces 1000 membres, tu en as une centaine qui lag ? Tu te retrouves très vite avec une base de donnée surchargée... Et un serveur qui refuse des connexions, renvoie des messages d'erreurs et qui devient très lent à cause de ça.
Avec mysqli tu as juste à dire " mysqli::close " et c'est bouclé. C'est décidé pour moi je vais passer sur mysqli, je laisse tomber PDO car je ne compte pas utiliser autre chose que mysql et il y a trop de points obscurs qui en font quelque chose qui n'est pas fiable à mes yeux... J'y retournerais si il y a une future mise à jour qui nous permet de fermer une connexion avec certitude.

-
Edité par Konkonbre 25 octobre 2015 à 21:21:36