C'est persistant parce que ça persiste (on ne ferme pas la connexion pour la réouvrir).
La solution de pool sert un un autre objectif (celui de réduire le nombre de connexions simultanées en permettant leur réutilisation le plus vite possible)
L'architecture de php ce sont des exécutions très courtes et parallèles. La connexion est donc relachée très rapidement, à la fin du traitement de la requete. On arrive presque avec une bijection entre l'utilisation des requêtes SQL et le traitement des requetes HTTP. Du coup autant attacher en dur une connexion par fil d'exécution et laisser la gestion du pool directement par Apache. Quand il y a besoin apache lance un nouveau fil d'exécution, et lors de la première exécution la connexion sql qui s'y rattache.
> persistant à un processus mais pas du tout à une application
Si ton argument c'est de dire que c'est différent de Java alors on est bien d'accord. Mais sorti de là .... ta connexion persistante est persistante, elle évite des reconnexions trop fréquentes inutilement, le reste c'est du papier.
Le choix de PHP a l'avantage qu'il se dimensionne parfaitement : vu que les processus ne partagent rien entre eux on peut les multiplier autant qu'on veut, en local ou en distant, et redimensionner dynamiquement le tout sans aucun problème.
Avec une notion de machine virtuelle centrale on a toute une machine à gaz (même si elle est déjà fournie avec le langage).
Re: Durée de vie des objets et connexions permanentes...
C'est persistant parce que ça persiste (on ne ferme pas la connexion pour la réouvrir).
La solution de pool sert un un autre objectif (celui de réduire le nombre de connexions simultanées en permettant leur réutilisation le plus vite possible)
L'architecture de php ce sont des exécutions très courtes et parallèles. La connexion est donc relachée très rapidement, à la fin du traitement de la requete. On arrive presque avec une bijection entre l'utilisation des requêtes SQL et le traitement des requetes HTTP. Du coup autant attacher en dur une connexion par fil d'exécution et laisser la gestion du pool directement par Apache. Quand il y a besoin apache lance un nouveau fil d'exécution, et lors de la première exécution la connexion sql qui s'y rattache.
> persistant à un processus mais pas du tout à une application
Si ton argument c'est de dire que c'est différent de Java alors on est bien d'accord. Mais sorti de là .... ta connexion persistante est persistante, elle évite des reconnexions trop fréquentes inutilement, le reste c'est du papier.
Le choix de PHP a l'avantage qu'il se dimensionne parfaitement : vu que les processus ne partagent rien entre eux on peut les multiplier autant qu'on veut, en local ou en distant, et redimensionner dynamiquement le tout sans aucun problème.
Avec une notion de machine virtuelle centrale on a toute une machine à gaz (même si elle est déjà fournie avec le langage).
[ Répondre ]