JSP et MySQL : La connexion qui se ferme toute seule... sans prévenir...

Bonjour à tous,

Je participe au développement d'une application Web d'assez grande taille et je rencontre régulièrement un problème pour le moins "étrange".

Il arrive qu'en plein milieu de page (après les en-têtes inclus, où la connexion est crée ou récupérée de la session (pour limiter le nombre de connexions à la base)), la connexion se ferme, toute seule, d'elle même 8O => Erreurs qui apparaissent n'importe où et cassent toute la structure de l'affichage.

J'ai essayé de recréer une connexion en début de chaque page, de conserver la connexion dans la session, de récuperer cette connexion, la fermer et en recréer une, de ne vérifier que la connexion soit bien encore ouverte... De trouver un time-out quelque part pour l'agrandir... rien à faire...

Quelqu'un a t'il une idée ? Déjà rencontré le même problème ? (Même sans solution, je me sentirais déjà moins seul ^^)

Pour information, nous travaillons sur Tomcat 5.5 et MySQL 4.1.9 avec les drivers JDBC correspondant.

Merci d'avance,
Maxime

Quel systeme de connexion utilises-tu ? le Pool Tomcat? Un pool fait par vous même?

Montre nous tes fichiers de proprietes et comment tu ouvres et ferme tes connexions.

C'est aussi à cela que sert le modele MVC, à ne pas faire d'acces base dans une JSP, mais plutot dans une action (ou servlet) et uniquement transmettre les réponses à la JSP via l'objet Request. Cela evite ce genre de probleme ou au moins permet de trouver des solutions plus facilement.

Citation:

---

Envoyé par T.NightGlow

Bonjour à tous,
Il arrive qu'en plein milieu de page (après les en-têtes inclus, où la connexion est crée ou récupérée de la session (pour limiter le nombre de connexions à la base)),
Maxime

---

Hello,

Je ne pense pas que stocker une connexion en session te permet de limiter les connexion...:aie:

Je suis d'accord avec yolepro, montre nous un peu le code...
Je pense qu'il doit y avoir certain problème de conception si vous accèder directement au modèle depuis la JSP...;)

Bien, en fait, le problème ne se pose plus trop ces derniers temps (il y avait un "conn.close()" qui trainait en bas d'une page, mais ça touchait d'autres pages, mais on a plus vu l'erreur depuis un moment...)

Quelques bouts de codes :

Code:

---

1 2 3 4 5 6 7 8 9 10

Connection conn; String basename="BD_TNG"; String serveur_bd="127.0.0.1"; if(session.getAttribute("conn")!=null){ conn = (Connection) session.getAttribute("conn"); }else{ Class.forName( "com.mysql.jdbc.Driver" ); conn = DriverManager.getConnection("jdbc:mysql://"+serveur_bd+":3306/"+basename,"root",""); session.setAttribute("conn",conn); }

---

Il y avait aussi un écouteur qui était censé fermer la connexion à la destruction de la session, mais nous l'avons finalement supprimer (session fermée => objet connection finalisé => connexion fermée).

Je me demande d'ailleurs s'il n'était pas responsable :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

class DeconnectionListener implements HttpSessionBindingListener{ private Connection myConn=null;   public DeconnectionListener(Connection conn) { super(); myConn=conn; }   // Add a connection to be closed when the session expires public void setConn(Connection conn) { myConn = conn; }   // Binding this object to the session has no additional effects. // @param event the session bind event. public void valueBound(HttpSessionBindingEvent event) { return; }   // When this object is unbound from the session (including upon session // expiry) the connection that has been added is closed. // @param event the session unbind event. public void valueUnbound(HttpSessionBindingEvent event) { try{ if(myConn!=null&&!myConn.isClosed()){ myConn.close(); } }catch(Exception e){ //Ben... Do know what to do... } return; } }

---

Un objet de cette classe était passé en attribut de session après avoir été créé avec l'objet connection en paramètre.

Salut

A mon avis tout cela est très très dangereux et va contre toute logique programmative: laisser la connexion en session est une très très mauvaise idée.

Ne vaut-il pas mieux utiliser un pool de connexions ???

Secundo, laisser la connection se fermer quand l'objet est finalisé me semble trés arbitraire aussi. Personellement j'aurai opté pour la solution du listener de session pour être certain de fermer la connection de façon programmative quand la session est invalidée.

Imaginons que la mémoire de la Jvm de soit pas trop encombrée, il se peut que l'objet connexion soit finalisé dans 10mn, ou plus si le besoin de mémoire ne se fait pas sentir... donc tout ça est trés arbitraire et tu peux conserver ta connexion encore ouverte un certain temps.

Un régle d'or pour moi et de toujours avoir la main sur les décisions et les actions d'un programme et ne jamais laisser la machine viertuelle ou autre compilateur remplacer les traitements que nous aurions pu mettre en place.

En fait, le problème s'était posé à moi la première fois lorsque j'étais à la fac et que nous ouvrions une connexion en début de page et la fermions en fin de page : le nombre de connexions au niveau du serveur Oracle était rapidement excédé (timeout 15 min entre la cloture de l'objet Connexion et l'appréciation de l'état fermée par le serveur bd). Le serveur bd ne nous accordait alors plus aucune "nouvelle" connexion.

Nous avions alors opté pour la conservation d'une connexion unique par utilisateur (donc conservée dans la session). Et pour éviter les déconnexions sauvages (fermetures du navigateur sans appel de la jsp qui ferme la session), nous avions utilisé ce système de Listener.

Maintenant, je suppose qu'un pool peut permettre d'obtenir une meilleur gestion des connexions, il va falloir que je me penche sur la question.

Edit : Lorsque la session est invalidée (soit explicitement, soit par le time out), tous les objets qui lui sont liés (en attributs) n'ont plus de références, ils sont donc collectés par le gc pour être finalisés. La connexion est donc fermée presque aussi tôt que la session (dans mon cas, il y a beaucoup d'appels aux GC, étant donné le trafic).

Néanmoins pour une programmation plus propre, penche toi sur le pool. Tu as DBCP tu es gratuit.