Pourquoi doit-on fermer les connexions sql ?

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 même connexion (java.sql.Connection) pour répondre à toutes les requêtes ?
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 chère ?
Les instances de Connection ne sont peut être pas synchronisées alors qu'elles devraient l'être pour assurer une cohérence? mais alors la ca couterait trop cher.

PS : c'est dans la section java général car j'ai pas trouvé mieux .

Citation:

---

Envoyé par 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 même connexion (java.sql.Connection) pour répondre à toutes les requêtes ?
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 chère ?
Les instances de Connection ne sont peut être pas synchronisées alors qu'elles devraient l'être pour assurer une cohérence? mais alors la ca couterait trop cher.

PS : c'est dans la section java général car j'ai pas trouvé mieux .

---

Tiens bizard, moi c'est exactement ce que je fais, je me connecte à la BDD dès le lancement de l'application et je me deconnecte qd j'arrête l'application (plus ou moins proprement).Initialiser une connection à la BDD à chaque requête est "très" couteux en terme de perf.
Corrigez moi si je me trompe. ;)

Salut,


Déjà la classe Connection n'est pas thread-safe, donc son utilisation depuis différents threads peut effectivement poser problème et est clairement à éviter sans synchronisation supplémentaire...

En règle général on se limite à l'utiliser dans un seul thread.

Ensuite cela dépend fortement du type d'application !

• Dans une application desktop on peut tout à fait ouvrir la connexion du début du programme et la fermer à la fin.
• Dans une application web c'est assez délicat car on peut se retrouver avec plusieurs accès simultané et on a alors besoin de multiples connexions...
  Toutefois on utilise alors des Pools de connexion qui "recycle" les connexions une fois fermées ;)
  Dans ce cas la demande de connexion et sa fermeture n'a qu'un coût minime, et on peut ainsi demander une connexion par client (c'est bien plus simple et plus performant que de mettre en place soit-même un mécanisme de synchronisation).

Dans tous les cas il faut également fermer les statement/resultset au plus tôt afin de bien libérer les ressources qui y sont associé...

a++

Merci de vos réponses, très intéressantes.

Torg666,
pour ma part, je la ferme systématiquement la connexion après l'exécution de la requête (comme j'utilise un pool je présume que c'est pas si cher payé) mais justement je me suis demandé l'intérêt de la fermer :P

adiGuba,

Tu penses donc que les implémentations de Connection gèrent un état, pouvant être altéré suite à l'appel des différentes méthodes 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 méthode createStatement() ne modifie pas l'état de l'objet connection, je ne vois pas de risque à des appels createStatement() qui se chevauchent sur la même instance.

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

Sans oublier les mécanismes de commit/rollback/savepoint...


Tout cela sans compter sur les diverses implémentations qui pourrait utiliser des caches ou d'autres joyeusetés non thread-safe.



De toute manière tant qu'un objet n'est pas explicitement thread-safe on doit considérer qu'il ne l'est pas, car le simple fait d'exécuter deux méthodes en parallèle pourrait poser des problèmes divers et varié si cela n'a pas été prévu...

a++

adiGuba,

Très intéressant ta réponse.
Dans ce cas la, une appli ou bien un service pour etre plus général qui ne fait que de la lecture pourrait se contenter d'utiliser la même connexion, même dans un environnement web.

Car :
Autocommit, mode readonly, holdability : si j'utilise les mêmes paramètres pour chaque requête exécutée, c'est pas un problème.

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

Non car rien ne garantie que cela soit thread-safe pour autant : tu ne connais rien de l'implémentation du driver et des problèmes que cela pourrait poser !

Je dirais même que c'est à éviter car cela peut très bien marcher pendant longtemps, puis planter sans raison apparente ! Ce genre de bugs est très difficile à mettre en évidence, et donc tout autant difficile à trouver et à comprendre...


Dès que tu es dans du multi-thread il faut vraiment faire très attention aux éléments que tu partages entre les différents threads.

a++