jeudi 10 avril

Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Astuces :: Suivi :: RDF

Articles précédents : Articles

Liens connexes

Annonce de la 1.5 (256 hits)
Communauté francophone (401 hits)
Page du projet (245 hits)

Dépêche modérée par

Floxy

Dépêche éditée par

Articles : Zend Framework 1.5 : consolidation et disponibilité

Posté par Étienne Bersac (Jabber id, page perso, ). Modéré le 25 mars 2008.

Zend Technologies et PHP Company ont sorti la version 1.5 du Zend Framework, ce cadre d'application web en PHP sous licence de type BSD. Ce projet rassemble une importante communauté et notamment des grands noms de l'industrie : Google, IBM et même Microsoft.

Le support des API Google accueille en plus le service YouTube facilitant l'envoi, la vision, la recherche et le commentaire de vidéo YouTube directement dans votre site web. Zend Framework supporte désormais OpenID, LDAP et Microsoft InfoCard pour l'authentification. Le dernier étant le successeur de Passport.net.

Ubuntu 8.04 LTS alias Hardy Heron propose Zend Framework dans son dépôt Universe. Une bonne nouvelle pour la disponibilité du produit dans les installations de serveur à base d'Ubuntu. Canonical veut pousser PHP comme la solution de choix pour développer et déployer des applications Web modernes. Ceci tranche un peu avec la politique plutôt pro-Java de Red Hat.

Annonce de la 1.5 (256 hits)
Communauté francophone (401 hits)
Page du projet (245 hits)

> Lire la dépêche (23 commentaires, moyenne: 2,9).

Parmi les autres nouveautés, on compte notamment :

Support AJAX étendu, avec des aides pour automatiser la détection et la réponse aux requêtes AJAX bien plus facile ;
Moteur de recherche Lucene, une version PHP du moteur de recherche Apache Lucene, cette API permet de maintenir un index autorisant la recherche riche et rapide ;
Support de l'UTF-8 dans Zend_PDF, un sérieux concurrent à FPDF ;
Générateur de formulaire HTML ;
Factorisation de la mise-en-page.

Bien d'autres améliorations et corrections de bugs sont listées dans les journaux de développement. Zend_Framework brille par sa simplicité, sa flexibilité, son manuel et sa documentation. Pas besoin d'échaffaudage ou de serveur dédié !

Nouveautés

Posté par desfrenes () le 25/03/2008 à 09:06. (lien). Évalué à 2.

Je peux me tromper mais il me semble que le composant Zend_Search_Lucene n'est pas une nouveauté de cette version et est intégré depuis au moins la version 1.0.

"Factorisation de la mise-en-page." aka Zend_Layout :-)

"Support AJAX étendu, avec des aides pour automatiser la détection et la réponse aux requêtes AJAX bien plus facile ;"

A quel composant cela fait-il référence ?

[ Répondre ]

Zend/Canonical ?

Posté par Jonathan Ballet (Jabber id, ) le 25/03/2008 à 10:11. (lien). Évalué à 4.

Canonical veut pousser PHP comme la solution de choix pour développer et déployer des applications Web modernes. Ceci tranche un peu avec la politique plutôt pro-Java de Red Hat.

Étrange, sachant que Canonical développe à priori pas mal d'outils en Python, dont Launchpad ...
J'aurais plutôt pensé qu'ils pousseraient dans cette direction.

[ Répondre ]

[^]Re: Zend/Canonical ?

Posté par Olivier Faurax (Jabber id, page perso, ) le 26/03/2008 à 19:26. (lien). Évalué à 2.
Peut être qu'ils poussent dans le sens du vent....

En tout cas, y en a un qui pousse PHP et python, l'autre qui pousse Java et Novell qui développe tout en C#. J'allais oublier Mandriva en Perl :)

--
xmpp:ofaurax@jabber.fr

[ Répondre ]

TCPDF

Posté par Laurent J (page perso, ) le 25/03/2008 à 10:19. (lien). Évalué à 5.

> Support de l'UTF-8 dans Zend_PDF, un sérieux concurrent à FPDF

En même temps, ça fait longtemps que FPDF a un successeur, qui supporte l'UTF8 et d'autres évolutions : TCPDF

http://www.tecnick.com/public/code/cp_dpage.php?aiocp_dp=tcp(...)

[ Répondre ]

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

Posté par forc3 (page perso, ) le 25/03/2008 à 10:21. (lien). Évalué à 5.

C'est super bien d'avoir des connecteurs vers pleins de technologies,
mais est-ce qu'en fin php va arriver à ne pas devoir "réouvrir toutes les connexions" vers tous ces services tiers à chaque connexion d'un internaute ?

Zend facilite énormément les choses, mais pourquoi est-ce encore impossible d'avoir à l'heure actuelle
un objet User qui tournerait dans php et qui persisterait
entre les connexion de l'utilisateur correspondant ?
A quoi ca sert un objet si sa durée de vie est nulle ?

Le cache permet d'avoir du code déjà compilé, c'est bien, l'étape suivante serait d'enfin pouvoir réutiliser des connexions ouvertes ...

Se reconnecter à Mysql pour chaque page, au LDAP ...
Reconstruire entièrement le cache memcache à chaque connexion pour pouvoir bénéfichier du consistent hashing.
( se reconnecter à tous les serveurs memcache à chaque appel de page ... c'est n'importe quoi)

Un frein majeur à l'utilisation de php c'est tout simplement que php ne dispose pas de machine virtuelle tournant en dehors du contexte apache.

Nombreux sont les sites (ou framework) qui ont recours à des crons pour faire des tâches schédulées alors que si php pouvait
être actif tout le temps ces tâches pourraient être exécutées simplement...

Si php pouvait s'installer facilement en mode machine virtuelle, il serait alors le champion toute catégories des developpements web.

Le problème reste que le langage n'a pas été prévu pour. Et qu'un changement dans ce sens serait très certainement très couteux.

Comment faites-vous alors pour contourner ce problème ?
Ces problèmes ne vous gênent pas ?

[ Répondre ]

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

Posté par Bruno Michel (Jabber id, page perso, ) le 25/03/2008 à 10:47. (lien). Évalué à 3.
Comment faites-vous alors pour contourner ce problème ?

Oh, bah c'est simple : je n'utilise plus PHP, mais rails. Ca marche aussi avec un tas d'autres langages/frameworks.

Si php pouvait s'installer facilement en mode machine virtuelle, il serait alors le champion toute catégories des developpements web.

Faut pas exagérer, PHP a des qualités, mais il a aussi de gros défauts, à commencer avec son API qui n'est ni orientée-objet, ni cohérente.

[ Répondre ]
- [^]Re: Durée de vie des objets et connexions permanentes...
  
  Posté par Rouzik (page perso, ) le 25/03/2008 à 10:55. (lien). Évalué à 5.
  "Faut pas exagérer, PHP a des qualités, mais il a aussi de gros défauts, à commencer avec son API qui n'est ni orientée-objet, ni cohérente."
  
  Ca pour ne pas être cohérente c'est clair :-( Pour l'orientation object de l'API, il y a maintenant la SPL qui s'enrichie, et niveau cohérente de noms de fonctions le ménage est prévu dans PHP 6.
  
  Mais bon il ne faut pas oublier que PHP n'est pas un langage objet à la base comme Rails ou Java. Comme C à l'époque s'est enrichi du C++, PHP doit effectuer sa mutuation sans perdre son origine procédurale. Bref continuer à proposer les deux approches.
  
  [ Répondre ]
  - [^]Re: Durée de vie des objets et connexions permanentes...
    
    Posté par Jean Boussier (Jabber id, ) le 26/03/2008 à 15:44. (lien). Évalué à 2.
    > PHP n'est pas un langage objet à la base comme Rails ou Java.
    
    Rails ? Tu voulais sûrement dire Ruby ?
    
    Je sais je chipote mais bon... d'autant plus qu'avec Ruby comme avec Python on peux coder strictement en procédural.
    
    [ Répondre ]
- [+] [^]Re: Durée de vie des objets et connexions permanentes...
  
  Posté par PierreJ () le 26/03/2008 à 14:07. (lien). Évalué à -2.
  > Faut pas exagérer, PHP a des qualités, mais il a aussi de gros défauts, à commencer avec son API qui n'est ni orientée-objet, ni cohérente.
  
  Trolleur ignorant > /dev/null
  
  [ Répondre ]

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

Posté par Rouzik (page perso, ) le 25/03/2008 à 10:49. (lien). Évalué à 2.
"Se reconnecter à Mysql pour chaque page, au LDAP ..."

Euh mysql_pconnect tu connais? :-) Cette fonction existe depuis le débt du PHP4 soit 2001. Et depuis avec PDO et le PHP5 (2004) ça s'est étendu aux autres types de DB.

Quant à la persistance des objets, en JAVA comme en PHP il faut passer par une surcouche (EJB3, JDO, Hibernate etc.. pour JAVA, Propel, PEAR, EZPDO, Metastorage etc... pour PHP. ) incluse ou non dans un framework. Le Zend Framework en inclue une, tout comme Jelix, Symphony et consors

Par contre pour LDAP, tu as raison, il n'y a rien à ma connaissance en PHP. Quoique je n'ai pas étudié les composants dédiés des frameworks comme Zend.

Quant à la pseudo-persistance à la mano d'objet, tu peux faire en PHP comme en JAVA une sérialisation de l'objet et le stocker où tu veux durant ce temps (cache, session etc...).

[ Répondre ]
- [^]Re: Durée de vie des objets et connexions permanentes...
  
  Posté par forc3 (page perso, ) le 25/03/2008 à 11:58. (lien). Évalué à 3.
  "Euh mysql_pconnect tu connais? "
  
  Je crois que la relecture de la documentation t'est nécessaire...
  Le pconnect ne fonctionne que pendant la durée de vie du script.
  
  Php s'arrête entre chaque page, ainsi que toute tes connexions SQL, pconnect ou pas.
  
  Le problème ne vient pas du manque de fonction dite persistentes, mais juste du fait que PHP vit et meurt en même temps que la requète de l'utilisateur.
  
  En cours, il n'est pas possible d'avoir des connexions persistentes avec un php fonctionnant en mod_php. Et cela sur n'importe quelle technologie.(LDAP, RADius, *SQL, ...)
  
  [ Répondre ]
  - [^]Re: Durée de vie des objets et connexions permanentes...
    
    Posté par Guillaume Smet (page perso, ) le 25/03/2008 à 12:22. (lien). Évalué à 4.
    Non, tu as du confondre avec une utilisation en mode CGI.
    
    En utilisant PHP en mode module sous Apache, PHP s'arrête entre chaque page, pas le fils Apache et c'est le fils Apache qui maintient la connexion que tu récupères à l'exécution de chaque fils PHP.
    
    Voir http://fr2.php.net/manual/en/features.persistent-connections(...) (il y a une section qui concerne le module Apache) et c'est très facile de vérifier en le testant (la majorité de nos applications PHP/PostgreSQL sont en connexions persistentes et cela fonctionne effectivement comme attendu).
    
    --
    Guillaume
    
    [ Répondre ]
    - [^]Re: Durée de vie des objets et connexions permanentes...
      
      Posté par forc3 (page perso, ) le 25/03/2008 à 13:50. (lien). Évalué à 1.
      "En utilisant PHP en mode module sous Apache, PHP s'arrête entre chaque page, pas le fils
      Apache et c'est le fils Apache qui maintient la connexion que tu récupères à l'exécution de chaque fils PHP."
      
      On se place dans le cas de processus ou de thread ?
      
      Donc si nous faisions un 'ls -l' dans /proc/piddufilsapache/fd
      nous devrions voir les connexions vers la base mysql par exemple ?
      Cette liste sera remise à jour tout au long de la journée ?
      
      Au démarrage de apache toutes les connexions se font d'un coup puis sont
      partagées entre les sessions php ?
      
      Et lorsque ce fils la meurt, que deviennent les connexions ?
      Ce fils là ne meurt jamais ?
      
      Je n'arrive pas a comprendre comment les connexions sont ensuite partagées ?
      Un mécanisme d'ipc permet à php de donner ses structures mysql à des fils nouvellement créés ?
      
      Je ne comprends plus rien à PHP ou alors il a grandement évolué dans sa version 5...
      
      [ Répondre ]
      - [^]Re: Durée de vie des objets et connexions permanentes...
        
        Posté par Guillaume Smet (page perso, ) le 25/03/2008 à 14:07. (lien). Évalué à 3.
        On se place dans le cas de processus ou de thread ?
        
        L'un ou l'autre suivant le MPM Apache utilisé (prefork ou worker).
        
        Au démarrage de apache toutes les connexions se font d'un coup puis sont partagées entre les sessions php ?
        
        Non. Quand tu crées ta connexion avec un *_pconnect (donc la première fois que le fils va exécuter une page PHP qui fait un appel à une fonction *_pconnect), le fils Apache conserve la connexion pour toute sa durée de vie.
        
        Et lorsque ce fils la meurt, que deviennent les connexions ?
        
        La connexion est fermée. C'est l'un des moyens de garantir que tes connexions vont se fermer une fois de temps en temps. Ca fait du ménage.
        
        Je n'arrive pas a comprendre comment les connexions sont ensuite partagées ?
        
        Elles ne sont pas partagées.
        
        Pour chaque fils Apache et pour un DSN donné, tu as une et une seule connexion.
        Toutes les requêtes qui sont traitées par ce fils utilisent la même connexion.
        Les autres fils ont leur connexion propre.
        
        Donc 30 fils Apache qui ont au moins fait un _pconnect durant leur vie = 30 connexions persistentes à la base de données. S'ils se sont connectées à 3 bases de données différentes (plusieurs applications avec des bases différentes), ça te fait 3 connexions par fils donc 90 connexions établies.
        
        On en arrive vite à utiliser un pool de connexions entre les serveurs web et la base, du coup (en tout cas pour du PostgreSQL).
        
        Je ne comprends plus rien à PHP ou alors il a grandement évolué dans sa version 5...
        
        Euh, ça fonctionne comme ça depuis au moins les versions 4.0.x (je n'ai pas touché à PHP avant).
        
        [ Répondre ]
        
        [^]Re: Durée de vie des objets et connexions permanentes...
        
        Posté par forc3 (page perso, ) le 25/03/2008 à 14:36. (lien). Évalué à 1.
        Merci pour tes explications.
        Elles me confortent bien dans l'idée que nous n'avions pas la même notion de connexions persistantes.
        
        Tu me présentes des connexions qui sont réutilisables un certains temps, et ce n'est bien sûr pas du tout la définition de persistant.
        (persistant à un processus mais pas du tout à une application)
        
        Finalement tu évoques toi même que cette solution de pconnect n'est pas satisfaisante, et que par conséquent tu t'orientes vers une solution de pool.
        
        Pour moi, cela prouve parfaitement mes dire, pconnect n'a rien de persistant.
        (pour reprendre un autre commentaire, c'est une solution de bricoleurs)
        
        [ Répondre ]
        
        [^]Re: Durée de vie des objets et connexions permanentes...
        
        Posté par Guillaume Smet (page perso, ) le 25/03/2008 à 15:20. (lien). Évalué à 2.
        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 ]
        
        [^]Re: Durée de vie des objets et connexions permanentes...
        
        Posté par Éric (Jabber id, page perso, ) le 26/03/2008 à 01:08. (lien). Évalué à 3.
        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 ]
  - [^]Re: Durée de vie des objets et connexions permanentes...
    
    Posté par Éric (Jabber id, page perso, ) le 25/03/2008 à 13:24. (lien). Évalué à 4.
    > mais juste du fait que PHP vit et meurt en même temps que la requète de l'utilisateur.
    
    Ca n'est vrai que si tu fais du pur CGI, ce qui n'est recommandé pour presque aucun cas d'utilisation. Je te propose de te pencher très rapidement vers tous les modules liés au serveur web genre le module php pour apache) ou vers le fastcgi.
    Dans tous ces cas le moteur php reste bien présent et persistant. Si tout le contexte d'exécution est relancé à chaque fois, le chargement du binaire, le chargement des modules et les ressources définies explicitement pour être persistantes (genre les pconnect) restent bien en vie.
    
    > En cours, il n'est pas possible d'avoir des connexions persistentes avec un php fonctionnant en mod_php. Et cela sur n'importe quelle technologie.(LDAP, RADius, *SQL, ...)
    
    Faux. Factuellement faux. Que dire de plus ?
    Les *_pconnect et mécanismes de ce type fonctionnent très bien en persistant sur mod_php
    
    [ Répondre ]
- [^]Re: Durée de vie des objets et connexions permanentes...
  
  Posté par Laurent J (page perso, ) le 25/03/2008 à 12:13. (lien). Évalué à 4.
  >Quant à la persistance des objets, en JAVA comme en PHP il faut passer par une surcouche (EJB3, JDO, Hibernate etc.. pour JAVA, Propel, PEAR, EZPDO, Metastorage etc... pour PHP. ) incluse ou non dans un framework. Le Zend Framework en inclue une, tout comme Jelix, Symphony et consors
  
  Ah non pas du tout. Ces couches dans PHP n'ont rien de persistant. Ce sont juste des couches "objets" par dessus les bases de données. Le terme "persistance" qu'emploi certains ORM php (comme EZ), c'est de la publicité mensongère ! Une fois la page exécutée, les objets correspondant aux enregistrements sont détruits (mais pas les enregistrements bien sûr).
  
  PHP ne permet pas la persistance des objets, quels qu'ils soient. Une astuce de bricoleur, est de stocker les objets en sessions (serialisation, tout ça) mais ce n'est ni performant, ni pratique (va donc stocker en session les objets issues des résultats d'une requete SQL, si tu fais pas gaffe, ton serveur explose). On peut utiliser aussi des trucs comme sharedance http://sharedance.pureftpd.org/project/sharedance mais là encore, il y a de la serialisation/deserialisation derrière.
  
  Avec un serveur Java, on a de la "vraie" persistance, en ce sens où les objets restent en vie entre chaque requête http cliente (ils ne sont pas serialisés ou quoi que ce soit..).
  
  [ Répondre ]
  - [^]Re: Durée de vie des objets et connexions permanentes...
    
    Posté par Jonathan Ballet (Jabber id, ) le 25/03/2008 à 13:32. (lien). Évalué à 1.
    
    > Avec un serveur Java, on a de la "vraie" persistance, en ce sens où les objets restent en vie entre chaque requête http cliente (ils ne sont pas serialisés ou quoi que ce soit..).
    
    Quid de la mémoire utilisée par le serveur Java dans ce cas là ?
    
    PHP a cet "avantage" là de se vider complètement lorsque le script a fini de s'exécuter. Comment ça se passe en pratique en Java ?
    
    [ Répondre ]
    - [^]Re: Durée de vie des objets et connexions permanentes...
      
      Posté par windu.2b (Jabber id, page perso, ) le 25/03/2008 à 13:56. (lien). Évalué à 3.
      Ben... Comme d'hab' je dirais.
      
      C'est à dire que les objets "courts" (qui ne vivent que le temps d'une session, ou le temps d'une page) sont nettoyés par le GC.
      Les objets "longs" vivent indépendamment des connexions/sessions/visites et sont donc là tant que le serveur Java vit.
      
      Du moins, c'est ce que je suppose (je fais du Java J2SE, et non J2EE)
      
      [ Répondre ]

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

Posté par Éric (Jabber id, page perso, ) le 25/03/2008 à 13:28. (lien). Évalué à 8.
> Si php pouvait s'installer facilement en mode machine virtuelle, il serait alors le champion toute catégories des developpements web.

Et si c'était le cas il aurait les mêmes désavantages que les autres machines virtuelles.
L'avantage du modèle de PHP c'est justement le "share nothing", qui fait qu'on peut multiplier les serveurs à moindre cout quand on en a besoin, que l'installation est aussi simple qu'une copie de fichier, etc.

Certes il serait bien d'avoir éventuellement un espace de stockage et de partage persistant qui ne nécessite pas une sérialisation/désérialisation, mais surtout pas de machine virtuelle unique à la Java. Ca n'est pas du tout l'optique.

> Ces problèmes ne vous gênent pas ?

Bien sûr que des fois ça gêne, mais d'autres fois ça évite des problèmes aussi. C'est un choix d'architecture, et sérieusement ça apporte largement autant d'avantages que d'inconvénients.

[ Répondre ]
- [^]Re: Durée de vie des objets et connexions permanentes...
  
  Posté par kowalsky () le 25/03/2008 à 23:28. (lien). Évalué à 2.
  
  Certes il serait bien d'avoir éventuellement un espace de stockage et de partage persistant qui ne nécessite pas une sérialisation/désérialisation, mais surtout pas de machine virtuelle unique à la Java. Ca n'est pas du tout l'optique.
  
  Comment ça machine virtuelle unique java ?
  Moi sur mon serveur de dev, j'ai plusieur tomcat et plusieur JVM.
  
  J'ai faux ?
  
  --
  You got the money, I got the soul.
  
  [ Répondre ]

Revenir en haut de page

Articles précédents : Articles

Liens connexes

Dépêche modérée par

Dépêche éditée par

Articles : Zend Framework 1.5 : consolidation et disponibilité

Nouveautés

Zend/Canonical ?

[^]Re: Zend/Canonical ?

TCPDF

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

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

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

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

[+] [^]Re: Durée de vie des objets et connexions permanentes...

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

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

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

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

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

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

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

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

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

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

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

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

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

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