# Java > Gnral Java > Persistance des donnes >  Pourquoi doit-on fermer les connexions sql ?

## thebloodyman

Bonjour  tous,

Une question me taraude depuis quelques minutes. 
J'ai regard sur Google mais rien trouv.

Quelqu'un saurait pourquoi on n'utilise pas la mme connexion (java.sql.Connection) pour rpondre  toutes les requtes ?
En gros, on n'initialiserai une seule connexion pour toute l'appli, que l'on ne fermerait pas tant que l'appli tourne.

Garder une connexion  la base  en continu est peut etre trop chre ? 
Les instances de Connection ne sont peut tre pas synchronises alors qu'elles devraient l'tre pour assurer une cohrence?  mais alors la ca couterait trop cher.

PS : c'est dans la section java gnral car j'ai pas trouv mieux .

----------


## Torg666

> Bonjour  tous,
> 
> Une question me taraude depuis quelques minutes. 
> J'ai regard sur Google mais rien trouv.
> 
> Quelqu'un saurait pourquoi on n'utilise pas la mme connexion (java.sql.Connection) pour rpondre  toutes les requtes ?
> En gros, on n'initialiserai une seule connexion pour toute l'appli, que l'on ne fermerait pas tant que l'appli tourne.
> 
> Garder une connexion  la base  en continu est peut etre trop chre ? 
> ...


Tiens bizard, moi c'est exactement ce que je fais, je me connecte  la BDD ds le lancement de l'application et je me deconnecte qd j'arrte l'application (plus ou moins proprement).Initialiser une connection  la BDD  chaque requte est "trs" couteux en terme de perf.
Corrigez moi si je me trompe.  :;):

----------


## adiGuba

Salut,


Dj la classe Connection n'est pas thread-safe, donc son utilisation depuis diffrents threads peut effectivement poser problme et est clairement  viter sans synchronisation supplmentaire...

En rgle gnral on se limite  l'utiliser dans un seul thread.

Ensuite cela dpend fortement du type d'application !

Dans une application desktop on peut tout  fait ouvrir la connexion du dbut du programme et la fermer  la fin.Dans une application web c'est assez dlicat car on peut se retrouver avec plusieurs accs simultan et on a alors besoin de multiples connexions...
Toutefois on utilise alors des Pools de connexion qui "recycle" les connexions une fois fermes  :;): 
Dans ce cas la demande de connexion et sa fermeture n'a qu'un cot minime, et on peut ainsi demander une connexion par client (c'est bien plus simple et plus performant que de mettre en place soit-mme un mcanisme de synchronisation).


Dans tous les cas il faut galement fermer les statement/resultset au plus tt afin de bien librer les ressources qui y sont associ...

a++

----------


## thebloodyman

Merci de vos rponses, trs intressantes.

Torg666, 
pour ma part, je la ferme systmatiquement la connexion aprs l'excution de la requte (comme j'utilise un pool je prsume que c'est pas si cher pay) mais justement je me suis demand l'intrt de la fermer  ::P: 

adiGuba,

Tu penses donc que les implmentations de Connection grent un tat, pouvant tre altr suite  l'appel des diffrentes mthodes d'interrogation sql ? 
(je vais voir a ce soir chez moi  ::mouarf::  )
Car si ce n'est pas le cas,  quoi bon synchroniser ?

Par exemple, si la mthode createStatement() ne modifie pas l'tat de l'objet connection, je ne vois pas de risque  des appels  createStatement() qui se chevauchent sur la mme instance.

----------


## adiGuba

L'objet Connection est bel et bien un objet  tat. On peut dfinir l'autocommit, le mode readonly, l'holdability ainsi que d'autres attributs.

Sans oublier les mcanismes de commit/rollback/savepoint...


Tout cela sans compter sur les diverses implmentations qui pourrait utiliser des caches ou d'autres joyeusets non thread-safe.



De toute manire tant qu'un objet n'est pas explicitement thread-safe on doit considrer qu'il ne l'est pas, car le simple fait d'excuter deux mthodes en parallle pourrait poser des problmes divers et vari si cela n'a pas t prvu...

a++

----------


## thebloodyman

adiGuba,

Trs intressant ta rponse.
Dans ce cas la, une appli ou bien un service pour etre plus gnral qui ne fait que de la lecture pourrait se contenter d'utiliser la mme connexion, mme dans un environnement web.

Car : 
Autocommit, mode readonly, holdability : si j'utilise les mmes paramtres pour chaque requte excute, c'est pas un problme.

commit/rollback/savepoint (ou transactions) : si je fais que de la lecture, je n'en ai pas besoin.

----------


## adiGuba

Non car rien ne garantie que cela soit thread-safe pour autant : tu ne connais rien de l'implmentation du driver et des problmes que cela pourrait poser !

Je dirais mme que c'est  viter car cela peut trs bien marcher pendant longtemps, puis planter sans raison apparente ! Ce genre de bugs est trs difficile  mettre en vidence, et donc tout autant difficile  trouver et  comprendre...


Ds que tu es dans du multi-thread il faut vraiment faire trs attention aux lments que tu partages entre les diffrents threads.

a++

----------

