Version imprimable
Bonjour,
pour mon application qui tourne avec hibernate sous Tomcat, j'ai le soucis suivant:
Qd j'utilise l'appli, au bout d'un certain nombre de manipulations, j'ai une erreur telle que:
pourquoi ???Code:
2org.hibernate.exception.GenericJDBCException: Cannot open connection
pour ceux qui veulent voici le stack,
Code:
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
34
35
36
37
38
salut
je me suis battu lundi soir avec la même erreur...
Après avoir vérifié que ma base tournait, que la database utilisée dans l'url de connection était bonne, que ma chaine de connexion (url) était sur le bon port avec un user existant, que j'avais bien tous les jars nécessaires pour ma base de données, je me suis rendu compte d'une bête erreur de frappe dans le paramétrage...
as tu vérifié tous ces points ?
Oui, le pb est que l'application tourne normalement ... donc la connexion est ok au début !!!!
Le pb c au bout d'un moment qd je fais des tests, au enième lancement de l'appli, :aie: tomcat me lache ....
Je suis obligé de sortir de Netbeans (dans mon cas) et de le relancer pour refaire un deployment sur Tomcat, bref c pas cool.
Qu'est qui peut bien faire cela :roll:
merci
juste une solution, ya pas un pb de session, car souvent lors des tests, l'équipe fait des pages avant ou après et il y a des variables en session ...
c pas un pb de Null pointer mais les requetes sont définies en en not null mais Tomcat gère comment ???
ou alors unTimeout, je sais pas, mais ce pb peut arriver sur deux connexions différentes,
bref j'ai du mal et en plus qd je suis arrivé dans la boite pour faire un update, le pb était déjà.
je pense que cela devrait être courant, non:(
La configuration de ta source de données dans Tomcat doit avoir une borne max. Et d'après la stack, il devient impossible d'obtenir une nouvelle connexion du pool après un timeout d'attente. Je suppose donc que soit tu utilises trop de connexions simultanément, soit tu ne libère pas les connexions afin qu'elles puissent être rendues au pool.
Une explication détaillée ici : http://tomcat.apache.org/tomcat-4.1-...20pool%20leaks
Merci de ta reponse,
je suis le seul à être sur cette base parceque pas en dev, mais je vais effectivement regarder sur la liberation des données et dons des données en session.
Parceque je pense que le pb est sur la session 8O
ah la la, ça me rappelle un vieux soucis : nous avions une appli où, qq'un, on ouvrait une connexion à la BDD "en direct", cad sans passer par le pool général. Bien sur, cette connexion était jamais refermée ensuite
Du coup on avait des vieux plantages aléatoires (parce que dépendant aussi du nombre de session du pool effectivement actives) et on a vraiment galéré pour retrouver le bout de code fautif.
Bref, si tu as des connexions "qui fuient", cad toujours ouverte mais jamais fermée, tu as bien des problèmes comme les tiens après un temps aléatoire d'utilisation.
Ne peux tu pas vérifier le nombre de connexion actives sur ta bdd au cours du temps ?