Java

JDBC: conséquences d'une non-fermeture de connection et ou statement

Recherche :

Mot : Pseudo : Filtrer
Page : 1 2 Page Suivante Page Précédente Bas de page
Auteur	Sujet : JDBC: conséquences d'une non-fermeture de connection et ou statement

--greg--

Hop,

Voudrais juste savoir quelles POURRAIENT etre les conséquences (tous points de vue) si on "oubliait" de fermer une Connection jdbc, ou (ça m'interesse plus dans ce cas-ci), un Statement.

:jap:

Message édité par --greg-- le 31-07-2002 à 21:33:19

Publicité

--greg--

up, tudju

darklord

You're welcome

à long terme et dans un environnemnt web, ton proc est occupé à 100%

---------------
Just because you feel good does not make you right

--greg--

DarkLord a écrit a écrit :

à long terme et dans un environnemnt web, ton proc est occupé à 100%

elles vont pas se faire jeter toutes seules au bout d'un moment alors...

darklord

You're welcome

non

---------------
Just because you feel good does not make you right

--greg--

merde ça suxxe.
je sens qu'on va me faire chier dans pas lgtps.
putain de couille

darklord

You're welcome

--greg-- a écrit a écrit :

merde ça suxxe.
je sens qu'on va me faire chier dans pas lgtps.
putain de couille

t'as encore programmé comme un porc toi

---------------
Just because you feel good does not make you right

benou

DarkLord a écrit a écrit :

à long terme et dans un environnemnt web, ton proc est occupé à 100%

sûr ??? dans les finally du Statement ou du Connecion ca doit les fermer nan ? donc au bout d'un moment ils vont se fermer ...

darklord

You're welcome

en J2EE non.

Edit: ce que je veux dire c'est que j'ai déjà programmer une servlet simple qui faisait des requetes débiles et que j'oublias de fermer les connections. Au bout d'un certain temps (meme sans faire d'autre requete sur le serveur) ca boucle et mon serveur est occupé à 100%

un c.close() et tout rentre dans l'ordre ...

Maintenant c'est peut etre du à une config pourrie de la DB chez nous et ca ne m'étonnerait pas non plus

Message édité par darklord le 31-07-2002 à 22:36:40

---------------
Just because you feel good does not make you right

benou

ben ... pkoi ils ont pas foutu un close dans le finalize ??? ca reglerait la plupart des problèmes ...

Publicité

darklord

You're welcome

benou a écrit a écrit :

ben ... pkoi ils ont pas foutu un close dans le finalize ??? ca reglerait la plupart des problèmes ...

parce que c'est pas propre.

---------------
Just because you feel good does not make you right

--greg--

DarkLord a écrit a écrit :

t'as encore programmé comme un porc toi

c'était y'a LONGTEMPS.
(pour te dire, j'avais un truc fait en php que j'ai converti en jsp/servlet, tu vois le genre)
en fait les stmt je les fermais mais je retournais le resultset
(genre
Resulset rs = truc;
stmt.close();
con.close();

return rs;
[:vomi]
et ça marchait, bizarrement
mais mtnt, paf changement de serveur (chgt de drivers mysql au passage aussi, sans doute), et ça marche pu. (mais bizarrement ça ne produit aucune exception, le rs est juste vide). si je ferme pas le stmt avec de retourner le rs, ça marche le hic c que jpeux pu fermer le stmt apres quoi, ou alors faut que je refasse toute cette merde, mais niet.)

--greg--

euh en fait
dans ma methode de merde
si je fais

try {
blahblah
rs = truc;
return rs;
} finally {
stmt.close();
con.close();
}

, le finally il est executé quand exactement? avant que la methode ne retourne "pour du vrai", nan? ou pas du tout? bref, dans un cas comme dans l'autre, ça va pas m'aider...

benou

--greg-- a écrit a écrit :

euh en fait
dans ma methode de merde
si je fais

try {
blahblah
rs = truc;
return rs;
} finally {
stmt.close();
con.close();
}

, le finally il est executé quand exactement? avant que la methode ne retourne "pour du vrai", nan? ou pas du tout? bref, dans un cas comme dans l'autre, ça va pas m'aider...

le finally est toujours executé !!
là il ser aexecuté juste avant le return

--greg--

benou a écrit a écrit :

le finally est toujours executé !!
là il ser aexecuté juste avant le return

c bien ce qu'il me semblait.
bon ben
prout alors, je crois.

benou

DarkLord a écrit a écrit :

parce que c'est pas propre.

je vos pas le problème que ca te pose ...

Code :

protected void finalize() throws Throwable {
if (! isClosed())
close();
}

--greg--

en fait
si ça se trouve cette methode finalize est implementée dans les drivers. auquel cas, j'ai pas de soucis tant que ce sont les memes drivers qui sont utilisés..?

edit: ha ben tfaçons c pas le cas

Message édité par --greg-- le 01-08-2002 à 00:03:16

benou

--greg-- a écrit a écrit :

en fait
si ça se trouve cette methode finalize est implementée dans les drivers. auquel cas, j'ai pas de soucis tant que ce sont les memes drivers qui sont utilisés..?

edit: ha ben tfaçons c pas le cas

comment tu sais ? t'as les sources ?

et en principe oui, c'est là de dans que ca devrait être implémenté ...

--greg--

benou a écrit a écrit :

comment tu sais ? t'as les sources ?

et en principe oui, c'est là de dans que ca devrait être implémenté ...

yep, j'ai les sources, et c'est pas implementé.

chapi456

benou a écrit a écrit :

je vos pas le problème que ca te pose ...

Code :

protected void finalize() throws Throwable {
if (! isClosed())
close();
}

Le probleme c'est justement quand tu veux retourner un ResultSet, si tu fermes le Statement, le ResultSet est vidé alors ca devient un peu chiant ...

Et puis pour les connections, normalement, y'a un timer qui les tuent au bout d'un certain temps (20 minutes je crois).
D'autre part, si tu fermes pas tes connections, tu satures la base en ouvrant trop de curseurs et la tu te fais jeter (en tout cas sur Oracle) !

benou

chapi456 a écrit a écrit :

Le probleme c'est justement quand tu veux retourner un ResultSet, si tu fermes le Statement, le ResultSet est vidé alors ca devient un peu chiant ...

ben nan : il doit y avoir une réf au statement dans le resultset => il sera pas garbagé !

bizarre, j'étais vraimentpersuadé que ca y était ...

chapi456

ben c'est plutot le contraire, c'est le resultset qui est relié au statement ... donc il est vidé dès que tu close le statement ... c'est dans la doc, c'est pas une invention de ma part !

benou

chapi456 a écrit a écrit :

ben c'est plutot le contraire, c'est le resultset qui est relié au statement ... donc il est vidé dès que tu close le statement ... c'est dans la doc, c'est pas une invention de ma part !

j'ai pas dit que c'était pas le cas, j'ai juste dit que si le resultset contenanit une ref vers le statement (ce qui de grandes chances d'être le cas vu que les 2 objets sont liés) on ne risquait pas de perdre le resultset à cause du garbage collectig du statement ...

- Renaud -

Pour info, certaines BD (DB2 par ex) refusent de commiter si des rs ou des stmt sont ouverts.

Renaud

--greg--

- Renaud - a écrit a écrit :

Pour info, certaines BD (DB2 par ex) refusent de commiter si des rs ou des stmt sont ouverts.

Renaud

euh ? et il faut commiter quand on récupéré un resultset? :heink:
(je doute pas de ta parole, mais je capte pas l'idée là)

edit: bon j'avais pas compris ce que tu disais, désolé

Message édité par --greg-- le 02-08-2002 à 18:36:54

R3g

fonctionnaire certifié ITIL

un conseil : le mieux c'est de faire :

Code :

finally {
try{ stmt.close(); } catch(SQLException e) {}
try{ con.close(); } catch(SQLException e) {}
}

pour être sûr que la connection se ferme même dans les pires conditions de poisse

--greg--

R3g a écrit a écrit :

un conseil : le mieux c'est de faire :

Code :

finally {
try{ stmt.close(); } catch(SQLException e) {}
try{ con.close(); } catch(SQLException e) {}
}

pour être sûr que la connection se ferme même dans les pires conditions de poisse

bon
he
je sais comment on gere une cnx merci
faut tout lire

krosso

j'suis à la bourre

--greg-- a écrit a écrit :

Hop,
Voudrais juste savoir quelles POURRAIENT etre les conséquences (tous points de vue) si on "oubliait" de fermer une Connection jdbc, ou (ça m'interesse plus dans ce cas-ci), un Statement.
:jap:

Si tu dois changer ton code, penses à utiliser un pool de connexions plutôt que d'en ouvrir(-fermer) une à chaque fois que t'en as besoin.

--greg--

krosso a écrit a écrit :

Si tu dois changer ton code, penses à utiliser un pool de connexions plutôt que d'en ouvrir(-fermer) une à chaque fois que t'en as besoin.

:heink:

El_gringo

--greg-- a écrit a écrit :

:heink:

T'as qu'a utiliser protomatter (fait un recherche sur google, tu tombera direct dessus), ça permet de fermer automatiquement les connections inactives au bout d'un certain temps que tu fixes toi même.
En fait, c un pool de connection, mais tu peux très bien l'utiliser pour une seule connection.
L'avantage, c que c'est l'implémentation d'un driver JDBC, du coup, t'auras pas grand chose à changer ds ton code si tu veux mettre ça em place.
Bon, normalement, cette option de pouvoir fermer les connections inactives, c pas fait pour être utilisé en production, bref, ça sera un peu crade, ms bon, apparement ton truc l'est déja pas mal, non !?

Message édité par El_gringo le 05-08-2002 à 16:30:16

darklord

You're welcome

ouah comme il te cherche l'ot là :lol:

---------------
Just because you feel good does not make you right

--greg--

el_gringo, j'ai failli t'engueuler
mais j'ai lu la fin de ton message qui est plus interessante

je SAIS ce qu'est un pool de cnx, je SAIS comment on utilise des cns, slt à l'epoque ou j'ai écrit la merde en question, manifestement je savais pas

l'idée d'utiliser protomatter cela dit c pas trop con: j'imagine qu'il s'utilise de maniere transparente et que je pourrais donc simplement remplacer le nom de mon driver?

El_gringo

--greg-- a écrit a écrit :

el_gringo, j'ai failli t'engueuler
mais j'ai lu la fin de ton message qui est plus interessante

je SAIS ce qu'est un pool de cnx, je SAIS comment on utilise des cns, slt à l'epoque ou j'ai écrit la merde en question, manifestement je savais pas

l'idée d'utiliser protomatter cela dit c pas trop con: j'imagine qu'il s'utilise de maniere transparente et que je pourrais donc simplement remplacer le nom de mon driver?

J'espère bien que tu sais ce qu'est un pool de connection. Bon, t pas encore un vieux sage du Java comme Darklord ou Benou, ms je t'attriburais qd même le status de grand garçon du Java, ce qui est déja pas mal, non !? )
Non, bon, je fais exprès pr t'emmerder parce que tu m'énerves, j'trouve que t'as un air supérieur quand tu t'adresses à moi (genre, mon idée est "pas trop conne". Ouah, ça c du remerciement comme je les aimes !)

Ouais, protomatter il s'utilise de manière transparente, c ce que j'essayais de te faire comprendre en te disant que un pool sous la forme d'un driver JDBC...

Message édité par El_gringo le 05-08-2002 à 17:45:07

--greg--

el_gringo a écrit a écrit :

Non, bon, je fais exprès pr t'emmerder parce que tu m'énerves, j'trouve que t'as un air supérieur quand tu t'adresses à moi (genre, mon idée est "pas trop conne". Ouah, ça c du remerciement comme je les aimes !)

disons que tu ne m'as pas toujours fais la meilleure impression au niveau java, du moins ds tes 1er posts...

el_gringo a écrit a écrit :

Ouais, protomatter il s'utilise de manière transparente

:jap:

el_gringo a écrit a écrit :

, c ce que j'essayais de te faire comprendre en te disant que un pool sous la forme d'un driver JDBC...:D

comme il me provoque!!! [:biscuiteur]

Message édité par --greg-- le 05-08-2002 à 17:48:47

El_gringo

--greg-- a écrit a écrit :

disons que tu ne m'as pas toujours fais la meilleure impression au niveau java, du moins ds tes 1er posts...

comme il me provoque!!! [:biscuiteur]

hé oui, g appris (et j'apprend encore) le Java sans cours, sans livre, juste avec le forum et en me balladant sur qqs sites.
Du coup ça a pu m'ariver (et ça peut encore m'arriver) de poser des questions dont la réponse te parait évidente.
Si c le cas, tant mieux, tu pourras m'aider rapidement.

Non, parce que, là par contre, franchement, t'as pas fait fort quand même ! l'idée du pool de connection, t'aurais pu la trouver tout seul ! (non mais franchement, bon Dieu, c vrai quoi ! )

...c chiant hein !?

Allez, j'arrête de te faire chier, ms essaye de penser à ça la prochaine fois que t'auras envie de m'incendier pr une question que g posée qui te plais pas ! :hello:

Message édité par El_gringo le 05-08-2002 à 17:56:02

--greg--

nan mais à la base, la question que je posais, ct de savoir quelles pourraient etre les consequences d'une non fermeture de statement et ou de connections alors :fuck:

:lol:

et au fait, euh franchement, lis des bouquins, t'apprend +vite et +mieux que sur le net (crois moi, pas eu de cours non plus)

darklord

You're welcome

Ne te méprends pas sur --greg--

C'est un gars qui en a ds la tête. le truc c'est qu'il ne fait pas du Java depuis longtemps c'est tout. Ca vient avec le temps ce genre de choses

---------------
Just because you feel good does not make you right

--greg--

DarkLord a écrit a écrit :

Ne te méprends pas sur --greg--

C'est un gars qui en a ds la tête. le truc c'est qu'il ne fait pas du Java depuis longtemps c'est tout. Ca vient avec le temps ce genre de choses

:heink:

darklord

You're welcome

quoi t'es pas content ?

---------------
Just because you feel good does not make you right

--greg--

DarkLord a écrit a écrit :

quoi t'es pas content ?

:kaola:

Publicité

Page : 1 2

Page Suivante

Page Précédente

Haut de page

FORUM HardWare.fr

Programmation

Java

JDBC: conséquences d'une non-fermeture de connection et ou statement

Sujets relatifs
[Java-Jdbc] requêtes SQL n'aboutissant pas !	[JDBC] Driver Access
pb avec [ Multimania et php ] connection base de donnée .....	mysql et jdbc
pb fermeture session.. help!!!!! moi pa comprendre....	Warning (Connection FTP en PHP)
Vitesse de connection	[EJB]Connexion JDBC
[C,C++] Connection à une base MYSQL	Fermeture d'une page sans confirmation
Plus de sujets relatifs à : JDBC: conséquences d'une non-fermeture de connection et ou statement

Page générée en 0.096 secondes