ODBC faut il laisser la connexion ouverte ?

ODBC faut il laisser la connexion ouverte ? - SQL/NoSQL - Programmation

Marsh Posté le 08-01-2005 à 11:41:34    


Bonjour
 
Une petite question toute bete.
 
Faut il laisser la connexion avec la base de donnée ouverte du commencement de l'application jusqu'à la fin de celle ci.
Ou est il préférable d' ouvrir et de refermer la connexion à chaque fois qu'on l'utilise ?
Est ce long d'ouvrir la connexion à chaque fois ?
 
(l'application n'utilise pas continuelement la BDD, mais à chaque fois que l'utilisateur valide quelquechose je sauvegarde les informations dans la BDD)
 
Merci d'avance.

Reply

Marsh Posté le 08-01-2005 à 11:41:34   

Reply

Marsh Posté le 10-01-2005 à 02:36:58    

Ca dépends de plusieurs choses (j'en oublie certainement)
 
1) L'application est-elle multi-utilisateurs ? Si oui, alors si il y a mettons 50 utilisateurs qui ouvrent une connection à la base en permanence, et qui n'utilisent ces connections que ponctuellement, il se peut que tu aies un problème au niveau de la base (trop de sessions ouverte, gestion des transactions allourdies, etc.)
 
2) Tu ne te sers pas en permanance de la connection. Mais ouvres-tu/fermes-tu de façon intensive la connection ? L'ouverture et fermeture d'une connection n'est pas très longue, surtout si la base est en local. Mais ça peut rapidement devenir un point critique au niveau des performance de l'application, surtout si la base est sur un réseau lent.
 
Toutefois, il faut savoir que ODBC gère normalement la connection à sa sauce. C'est à dire que même si tu fermes la connection, il la laisse souvent ouverte, dans l'attente d'une réouverture quelques instants plus tard.
 
Cela dit, je pense que tu prends le problème à l'envers : as-tu besoin d'une connection ouverte en permance ou non ? Par exemple, vas-tu utiliser des transactions qui vont durer plusieurs écrans de suite, ou non ? Dans ce cas, alors il faudra obligatoirement conserver une connection ouverte, tout le long de la transaction au moins.
 
Dans le cadre d'une application Web, on utilise généralement des connection de type "pool de connection", ou "alive". C'est à dire qu'une unique connection implicite est ouverte pour toutes les pages du site, et ensuite, au niveau programmation, on va ouvrir/fermer des "sous-connections" dans cette connection principale. C'est ensuite le moteur du SGBD qui décide de conserver ou non la connection principale ouverte ou non, selon s'il y a des "sous-connections" ouvertes régulièrement ou non.
 
Pour une appli client/server, on utilise généralement une connection qui reste ouvrte tout le long de l'utilisation du programme, afin de gérer des transactions, et ne pas de soucier lors du traîtement des évènements de savoir si une connection est déjà ouverte ou non (par exemple, quand tu cliques sur "rafraîchir les données" ou "enregistrer", si tu n'ouvres pas systématiquement une connection tu seras obligé de vérifier qu'une connection n'a pas déjà été ouverte pour cet écran avant d'en ouvrir une ou de réutiliser l'existante.

Reply

Marsh Posté le 10-01-2005 à 02:42:00    

Ca dépends de plusieurs choses (j'en oublie certainement)
 
1) L'application est-elle multi-utilisateurs ? Si oui, alors si il y a mettons 50 utilisateurs qui ouvrent une connection à la base en permanence, et qui n'utilisent ces connections que ponctuellement, il se peut que tu aies un problème au niveau de la base (trop de sessions ouverte, gestion des transactions allourdies, etc.)
 
2) Tu ne te sers pas en permanance de la connection. Mais ouvres-tu/fermes-tu de façon intensive la connection ? L'ouverture et fermeture d'une connection n'est pas très longue, surtout si la base est en local. Mais ça peut rapidement devenir un point critique au niveau des performance de l'application, surtout si la base est sur un réseau lent.
 
Toutefois, il faut savoir que ODBC gère normalement la connection à sa sauce. C'est à dire que même si tu fermes la connection, il la laisse souvent ouverte, dans l'attente d'une réouverture quelques instants plus tard.
 
Cela dit, je pense que tu prends le problème à l'envers : as-tu besoin d'une connection ouverte en permance ou non ? Par exemple, vas-tu utiliser des transactions qui vont durer plusieurs écrans de suite, ou non ? Dans ce cas, alors il faudra obligatoirement conserver une connection ouverte, tout le long de la transaction au moins.
 
Dans le cadre d'une application Web, on utilise généralement des connection de type "pool de connection", ou "alive". C'est à dire qu'une unique connection implicite est ouverte pour toutes les pages du site, et ensuite, au niveau programmation, on va ouvrir/fermer des "sous-connections" dans cette connection principale. C'est ensuite le moteur du SGBD qui décide de conserver ou non la connection principale ouverte ou non, selon s'il y a des "sous-connections" ouvertes régulièrement ou non.
 
Pour une appli client/server, on utilise généralement une connection qui reste ouvrte tout le long de l'utilisation du programme, afin de gérer des transactions, et ne pas de soucier lors du traîtement des évènements de savoir si une connection est déjà ouverte ou non (par exemple, quand tu cliques sur "rafraîchir les données" ou "enregistrer", si tu n'ouvres pas systématiquement une connection tu seras obligé de vérifier qu'une connection n'a pas déjà été ouverte pour cet écran avant d'en ouvrir une ou de réutiliser l'existante.

Reply

Marsh Posté le 10-01-2005 à 07:10:03    

merci bcp pour cette reponse.
je crois que vu mon utilisation et ce que tu dis, qu'il faudrait mieux la fermer et la rouvrir histoire de ne pas surcharger le serveur de bdd.

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed