Non. C'est justement le boulot d'un connection pool (en combinaison avec le transaction manager).
Que ce soit transparent pour toi (instrumentation du code) ou explicite, le connection pool ne doit pas allouer une connexion à quelqu'un d'autre si elle n'a pas été relâchée correctement. Au-dessus de cela, il y a une gestion interne de restauration des sessions (en cas de connection perdue, par exemple) ou de réaliser les commit/rollback nécessaires.

L'appli ouverte? Benh c'est toi qui doit gérer ça, ça se partage pas entre appli, c'est typique à PHP, en dehors de PHP c'est toi qui gère de garder un socket ouvert tu sais

Mais comme ouvrir un socket, ça coûte "cher", au final, ça se gagne. A toi d'avoir un bon try/catch et du code propre, mais si t'as un code moisi, ça, c'est sûr que bon

OK merci

En fait il y a 2 applis : un webservice en java faite par une autre boîte (c'est elle qui a planté principalement), et une appli à moi en PHP mais qui provoque bcp moins d'accès (la première est publique on va dire, l'autre pas et ne sert qu'à une poignée de personnes).

J'ai lu par ailleurs que les connexions persistentes pouvaient être dangereuses car on ne sait pas toujours si on récupère une connexion "stable" (quid si l'appli qui l'a ouverte précédemment a planté en plein milieu d'une transaction, ce genre de choses).

Je dirais que la réponse est dépendante de ton archi, et de ses possibilités. Ton truc est en PHP, ou en natif?

Si c'est en PHP, t'as pas beaucoup de choix, mais il y a une connexion persistante qui permet de ne pas s'énerver, si t'es en FastCGI, logiquement il garde cela de page en page, tu gagnes quelques ms précieuses sur la connexion, et tu vas pas te prendre 200 connexions vu que t'es limité en termes de FastCGI.

En compilé je fais plus ou moins pareil, j'ai un pool de connexions ouvertes, et je vais pêcher dedans à chaque query. Si t'utilises l'API C, tu dois bien faire gaffe à ce que tu fais, pour pas exploser le bousin en demandant le result du query (qui est du dernier, donc si t'es en multithread benh.... pas forcément celui que tu crois ).

Dans d'autres cas je préfère le mode connecté/déconnecté, mais en fermant au bon moment (dès que je sais que j'ai fini, pas en fin de process), ça me permets de pas trop charger la mémoire. Mais dans les grandes lignes, le persistent a souvent ma préférence

Salut les nerds

Au boulot, on me pose une question à laquelle j'ai du mal à répondre : pour une appli web, vaut-il mieux utiliser un mode de connexion persistent à la base de données (utilisant un pool de connexions par appli), ou un mode où on se connecte et déconnecte à chaque requête http (qui est me semble-t-il le mode par défaut pour des applis PHP) ?
J'ai fait quelques recherches sur le sujet, mais il ne semble pas y avoir de consensus clair sur le sujet.

A la base, cette question fait suite à une appli qui a planté suite à un afflux massif de connexions simulatanées provoquant une erreur "too many connections" de mysql. En fait je pense que le problème provient principalement d'un rafraîchissement automatique continu d'une liste d'items qui est à mon avis codé sans cache et provoquer des tas de "select"... Je leur ai suggéré d'intercaler un cache comme redis, mais on m'a aussi parlé du mode de connexion à la base, d'où ma question.

Merci pour vos avis