[Communication jdbc-java] Frequence d'ouverture et fermeture de connection

Rebonjour :D ,

J'ai un classe nommé BDD qui gere toute la communication avec la base de donnée. Quand j'instancie cette classe au lancement du programme, j'ouvre la connection avec la BDD MySQL et je la ferme à la fin du programme.

Ma question est donc la suivante :

Dois-je ouvrir et fermer la connection pour chaque requete, ou la laisser en permanence ouverte ? Sachant que si je la laisse ouverte je pourrais initialiser (compiler) mes requetes SQL grâce aux PreparedStatement , ce qui accelerera la communication avec la BDD une fois la phase d'initialisation terminée.

A prendre en compte : La frequence d'appel de la BDD est soutenu car mon apllication est automatique(non utilisateur).

Voila j'aimerais avoir votre avis, :merci:

Du fait qu'elle soit automatique, garde plutot une stratégie de session longue comme tu le fais actuellement.

En outre, un nombre répété de sessions courtes devront te faire installer un pool de connexion pour ne pas "trop" faire trainer les demandes d'ouverture de connexion (puisqu'elles sont faites au départ de l'application). A très grande utilisation, la BDD lachera ou bien renverra quelques appels si sa file d'attente est remplie...

Donc en passant en sessions courtes : soit tu perds en temps d'execution (sans pool) soit tu risques de recevoir des erreurs de file d'attente pleine (avec pool) ... ce qui nuit donc aux perfs de ton appli ;)

Par contre, si tu veux encore plus optimiser le tout avec sessions longues, tu peux toujours threader tes requetes pour utiliser plusieurs sessions à la fois et donc utiliser un pool de connexion en plus ... mais ca n'est peut-être pas très utile dans ton cas ;).

Schema sans pool avec session longue:

Code:

---

1 2 3 4 5 6 7

----------------------------------> Temps d'execution R1--->S1 R2------>S1 R3--------->S1 R4------------>S1 R5--------------->S1

---

Ici donc, les requetes s'executent en série avec la même session longue

Schema (avec pool?), threads en session longue (3 sessions par exemple):

Code:

---

1 2 3 4 5 6 7

----------------------------------> Temps d'execution R1--->S1 R2--->S2 R3--->S3 R4------>S1 R5------>S2

---

Tu gagnes donc encore plus en temps ;)

Histoire de rajouter encore une précision, la seconde solution pourrait cependant apporter une complexite en matière d'accès concurrentiels ... donc à reflechir on dira ... ca dépendra de ton application mais pour des lectures par exemple, je pense que la solution sera bien plus optimiale :mrgreen:

:king: quelle reponse claire! merci bien :)

Je vais donc dans un premier temps garder la session longue sans pool car je manque de connaissances en ce qui concerne les pools de connexions et que mon apllication est deja longue a debugger.

Par contre je garde ta 2ème solution (session longue avec pool) en reserve au cas ou le temps de reponse de la BDD soit trop important.

Merci encore pour cette reponse qui m'est d'un grand secour ;)