Re: Durée de vie des objets et connexions permanentes...

Elles sont persistantes pour la durée de vie d'un fils que tu peux ajuster comme tu le souhaites.
Elles ne sont pas partagées, elles sont complètement indépendantes de l'application (ce qui est assez logique vu qu'il n'y a pas de notion d'application) mais elles sont persistantes.
Après, il est sûr que si tu souhaites trouver une définition qui te donne raison, ça ne me pose pas plus de souci que ça...

Note bien que ce que tu disais dans ton premier commentaire est :
"Se reconnecter à Mysql pour chaque page, au LDAP ..."
ce qui est donc faux comme nous te l'avons tous indiqué.

Tu devrais relire mon commentaire dans son entier et tu verras que je ne remets pas en cause la persistance par l'utilisation d'un pool de connexions.
Utiliser un pool résout une problématique différente. Ce n'est pas le problème de la persistance que je règle avec ça, c'est le problème d'avoir beaucoup trop de connexions sur ma base qu'il n'est vraiment utile quand j'ai beaucoup de fils Apache dont certains n'ont pas spécialement besoin de la base à l'instant t.

Après, qu'un pool de connexions utilisé en direct comme ce qu'il se fait en Java soit plus intelligent et plus économe en ressources, c'est une autre histoire. Note que même dans ce cas, les implémentations classiques de pool ferment en général les connexions au bout d'un certain temps pour en réouvrir d'autres. Et que de la même manière, tu peux avoir plein de connexions suivant les besoins de ton application et son utilisation.

Cela n'empêche pas de pouvoir trouver un équilibre tout à fait satisfaisant avec du PHP en module Apache et, pour ne pas le citer, PgBouncer.
Et certains trouvent même leur équilibre sans connection pooling additionnel.

[ Répondre ]