C’est cool pour PHP, je voulais pas dire que c’était pas “pro” mais juste pas répandu: si le client en demande j’y passerais, mais dans l’immédiat, j’ai pas besoin :).
un pool, ce n’est pas uniquement des connexions persistante: c’est un ensemble de connexions alloué à une tâche un certain temps, puis relibérées pour être réaffecté à n’importe quelle autre tâche: le nombre de connexion dans les pool peut être fixe ou variable dans le temps: on en alloue progressivement en fonction du besoin, avec une certaine limite.
bref: en jdbc: le driver ne s’en occupe pas, c’est la couche au dessus qui s’en occupe, donc la gestion de pool peut-être faite indépendament du driver jdbc fourni par l’editeur de basses de données.
ça ne me semble pas indispensable d’intégrer le pool au niveau du driver base de données, vu que ça peut être fait indépendamment.
ça ne me choque pas spécialement, mais je crains des spécificité des éditeurs, et au final des incompatibilité de sources PHP lors d’une migration entre bases :neutre:
Ouaip, ça manque parfois d’uniformité le Web. dommage qu’on ne voit pas des modules PHP comme on voit des modules Java (voire des interconnexions à la JNI).
Bon, je retourne à mes impressions swing (translate scale et autres paint) Si un jour quelqu’un fait une vraie API d’impression Le pire c’est que c’est microsoft qui serait le mieux placé pour ça, s’il n’étaient pas enfermé dans leur dot net et dcom. un petit webservice et hop!
Bah en fait c’est tout con… mais comment tu veux gérer dans un script qui tourne dans un thread des ressources d’un processus entier sans conflit ? Le pool, ça se fait au niveau du processus et chaque script PHP dans un serveur classique n’a d’incidence que sur son thread propre (tout ça, c’est géré par une couche du noyau PHP appelé TSRM pour Thread Safe Resource Management).
Donc à partir du moment où c’est techniquement pas possible, on fait faire ça par autre chose. PHP n’est pas Java, chacun ses atouts / faiblesses !
Oui enfin je doute de l’avenir de php s’il se base trop sur le côte “je m’attache à Apache (ou autre) pour gérer le temps d’une connexion le script d’un client” plutôt que “Apache me dit bonjour car je sais gérer un fichier, et je le fais dans un environnement dédié” (à la j2ee)).
Parce que c’est mignon de planquer les threads par une surcouche, sauf que tu peux plus synchroniser “simplement” (truc de base : tous les singletons, tout les accès à des caches, doivent se faire de manière synchrone).
(et le pire c’est que je suis pas un vieux codeur, j’ai à peine deux ans de java à mon actif, 7 de php…)