Oracle et problème de fermeture de resultset/statement

Perso, je n'ai pas eu le temps d'investiguer là dessus et j'ai contourné le problème.
Toutes mes fenêtres héritent d'une classe qui ferme la connexion quand je ferme la fenetre.
Ensuite, j'ai codé un gestionnaire de connexion qui lors du connect ne se reconnecte pas si une connexion est déjà active.
Donc avant chaque bloc d'instructions utilisant la BDD, je fait un connect qui reste souvent sans effet car déjà connecté.

Dans ton cas, je te suggère de mettre une connexion dans le header et une déconnexion dans le footer de ta page. Comme ça, tu limites le nombre de curseurs. SI les perfs suivent, ça peut être un bon compromis.

Bon courage ;)

Citation:

---

Envoyé par adil_vpb

Bref, je ferme mes statements, mais sur la BDD Oracle, et surtout sur OEM -> Instance -> Sessions : le programme "JDBC Thin Client" s'ajoute aux sessions à chaque fois que je rafraichi ma page !
...

---

Ce ne sont pas les statements qu'il faut fermer, c'est l'objet Connection...
Tu acquiers une connexion en début de cycle et tu la fermes à la fin du cycle.
Le pool de connexions permettra (généralement) d'avoir une connexion plus rapidement, mais si tu ne la libères pas, le problème restera le même.

A+

Bonjour,

Je découvre avec une certaine déception ce post (mais avec soulagement également) : j'ai rencontré exactement le même problème sur une application.
Je ne comprenais pas bien pourquoi les curseurs restaient absolument ouverts alors que je fermais bien les ResultSet et les PreparedStatement ...

Et il semblerait que vous confirmeriez bien qu'il faut absolument fermer la connexion pour libérer les cuseurs coté Oracle ?? Donc que le close() du ResultSet ne sert à rien ???

Moi je dis bravo les drivers OJDBC :king:

Bon, bin je vais aller re-coder la méthode qui gère la connexion pour la fermer à chaque fois, il n'y a plus que ca visiblement

Citation:

---

Envoyé par Baodai

...

Bon, bin je vais aller re-coder la méthode qui gère la connexion pour la fermer à chaque fois, il n'y a plus que ca visiblement

---

Attention, une connexion/déconnexion est couteuse en temps.
Il te faut trouver le bon compromis entre nombre de curseurs ouverts et temps passé à se connecter.

Pour l'utilisation des pools de connexion, je n'ai pas testé mais ça pourrait aider en cas de déconnexion/reconnexion à chaque fois.

Citation:

---

Envoyé par Baodai

Moi je dis bravo les drivers OJDBC :king:

---

Ce n'est pas un problème ODBC ou JDBC, c'est un fonctionnement normal.
La connexion sert de canal vers la DB, le statement est un objet qui permet d'exécuter des requêtes via le canal (Connection).
Tu peux créer et exécuter plusieurs statements avec la même connexion, ou des PreparedStatement etc...

Il semble cependant qu'avec Oracle, on puisse avoir un "connection.close()" qui ne libère pas la connexion côté serveur DB

Citation:

---

Envoyé par OButterlin

Ce n'est pas un problème ODBC ou JDBC, c'est un fonctionnement normal.
La connexion sert de canal vers la DB, le statement est un objet qui permet d'exécuter des requêtes via le canal (Connection).
Tu peux créer et exécuter plusieurs statements avec la même connexion, ou des PreparedStatement etc...

---

Oui, malheureusement on ne peut pas fermer les curseurs cotés Oracle sans fermer la connexion, alors qu'ils correspondent plutot à l'objet ResultSet.

Pour le pool de connexion, je ne pourrais à priori pas le mettre en place dans l'application que je traite (script shell qui appelle une classe Java qui effectue un chargement ... indépendament de l'application Web qui utilise bien un pool de connexion).
Je vais faire des tests en utilisant plusieurs connexions, trouver le bon compromis comme l'a dit lasticot69

Il n'y a pas besoin de plusieurs connexions, il suffit, en fin de cycle, de fermer LA connexion pour que tout ce qui s'y attache soit fermé (à moins bien sûr d'avoir besoin d'un grand nombre de statement et que ça dépasse le nombre autorisé par la connexion)

Citation:

---

Envoyé par lasticot69

Perso, je n'ai pas eu le temps d'investiguer là dessus et j'ai contourné le problème.
Toutes mes fenêtres héritent d'une classe qui ferme la connexion quand je ferme la fenetre.
Ensuite, j'ai codé un gestionnaire de connexion qui lors du connect ne se reconnecte pas si une connexion est déjà active.
Donc avant chaque bloc d'instructions utilisant la BDD, je fait un connect qui reste souvent sans effet car déjà connecté.

Dans ton cas, je te suggère de mettre une connexion dans le header et une déconnexion dans le footer de ta page. Comme ça, tu limites le nombre de curseurs. SI les perfs suivent, ça peut être un bon compromis.

Bon courage ;)

---

Bonjour,
là j'ai une petite idée et je pense que t'as la cité ci-dessus,
bon pourquoi pas d'utiliser un connect, comme le cas dans SQL+, je pense que OEM garde le meme programme ouvert (active si on met connect/inactive dans le cas de disconnect, et le kill dans le cas de exit !) j'ai pas encore tésté ce que je dis maintenant, mais peut étre ca ava résoudre le probléme, au lieu de faire une connexion à la BDD à chaque fois, on mets des connect ! :roll:
je ne sais pas, je vais tester ça bientôt .

Je viens de creuser un petit peu l'application que je dois debugger, et les choses se compliquent : elle n'utilise qu'une seule connexion du début à la fin, car une fois tout le traitement effectué, elle effectue un commit en cas de succès, et un rollback si la moindre Exception a été remontée ...

Il m'est donc impossible de fermer la connexion en cours de route, puisque cela oblige à commiter (ou "rollbacker") avant la fermeture, sauf erreur de ma part ?

J'ai donc 2 solutions qui me viennent en tête :
- Trouver une solution pour véritablement fermer ces curseurs sans fermer la connexion :mrgreen:
- Modifier le fonctionnel de l'application pour qu'il traite les données par plus petit paquets, afin que le nombre de curseur ne soit pas trop elevé. Cette 2° solution est évidement bien plus longue à mettre en place, et surtout je ne sais pas si elle est réalisable au niveau du fonctionnel.

Donc si qq1 me trouve une facon de réaliser la première, j'achète !!! :yaisse2:

Citation:

---

Envoyé par Baodai

Donc si qq1 me trouve une facon de réaliser la première, j'achète !!! :yaisse2:

---

:mouarf: c'est ce qu'on cherche ! mais bon ne t'inquiéte pas ! parce que tu vas acheter la solution, on va la trouver bientôt ! :mouarf:

je vais chercher comme même.

dis moi Lasticot69 je conais pas ton prénom ;) t'as pas pensé de manipuler la table v$session ?

Suite à conversation avec gentil DBA, il semblerait possible que fermer le ResultSet ET le PreparedStatement suffise à fermer le cursor coté Oracle ... en tout cas il me signale que l'outil que j'utilise pour surveiller les curseurs ouverts m'indique en réalité les curseurs en mémoire, pas forcément ouverts donc !!!

Je vais donc essayer de baisser le nombre de curseur max, re-modifier mon code pour avoir une seule connexion tout le long, mais qui ferme les ResultSet et PreparedStatement à chaque fois, et on verra bien si on fait sauter la limite :)

Je vous tiens au courant ;)

Edit : Quand je relis le premier post de Lasticot, je me dis que j'ai assez peu de chance que ca marche, vu qu'il avait déjà fermé le PreparedStatement et le ResultSet ... enfin bon, on ne sait jamais :?

Bon, j'ai tout modifié comme j'ai dis, j'ai changé le nombre de curseurs ouverts maxi avec la commande ci-dessous, j'ai lancé => pas de problème ...

Code:

---

alter system set open_cursors = 5;

---

Bon, je validerais tout ca demain avec contrôle avisé d'un DBA

Bonjour,
Est ce que vous pouvez me montrer la chaine de connexion que vous utilisez pour accéder à la BDD Oracle à partir du code java ?

Citation:

---

Envoyé par adil_vpb

Bonjour,
Est ce que vous pouvez me montrer la chaine de connexion que vous utilisez pour accéder à la BDD Oracle à partir du code java ?

---

Voici celle que j'utilise (cf tout premier post si besoin de plus d'info)

Code:

---

Connection con = DriverManager.getConnection("jdbc:oracle:thin:@guzet.**.net:1521:mydb","user","mdp");

---

Voici la mienne :

Code:

---

1 2	jdbc:oracle:thin:@NomOuIPMachine:1521:NomBase

---

Citation:

---

Envoyé par adil_vpb

Bonjour,
Est ce que vous pouvez me montrer la chaine de connexion que vous utilisez pour accéder à la BDD Oracle à partir du code java ?

---

Sinon tu peux aussi faire un semblant de recherche ou aller voir dans la FAQ

Et moi j'utilise :

Code:

---

Connection con = DriverManager.getConnection("jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=MYHOST)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=MYSERVICE.MYDOMAINE)))","user","mdp");

---

j'ai résolu le probléme de session, par la création de deux méthode, une pour ouvrir la connexion dans le Header de la page, et l'autre pour la clôturer dans le footer.
Aprés j'ai constaté un autre probléme, c'est le nombre de processe ! :roll:

j'ai dis que peut être ça dépend de la chaine de connexion, car dans mon cas c'est dispatcher je pense.

Y a t-il une différence entre les deux chaîne ?

La différence de chaine de connexion vient juste du fait que nous avons un fichier TNSNAMES.ORA et un SQLNET.ORA qui servent à éviter des paramétrages du type :

Code:

---

DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=MYHOST)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=MYSERVICE.MYDOMAINE))

---

Ces deux chaines fournissent les mêmes services.

Bon,
Concernant les chaine de connexion, j'ai posé cette question car dernierement j'ai laissé ma page pendant une large durée, presque une heure, avec une actualisation automatique toute les 20 seconds ! aprés j'ai constaté l'erreur suivante :

Code:

---

Connection refused(DESCRIPTION=(TMP=)(VSNNUM=150999297)(ERR=12516)(ERROR_STACK=(ERROR=(CODE=12516)(EMFI=4))))

---

je pense que c'est à cause des processes, chaque connexion à la BDD, crée un processe, c'est ce que je pense !
alors est ce que vous avez rencontré ce type d'erreur ?
Merci d'avance.

Bonjour,
Personne n'a jamais vu l'erreur citée dans mon dernier message?
:roll: