[ASP.NET] Meilleure façon de gérer la connexion à une base

J’essaye de trouver une solution propre et légère pour gérer la connexion à une base de données.
Le site que je conçoie aura à charge de délivrer du contenu hautement dynamique, et de gérer un certain nombre d’utilisateurs.

Je cherche donc le moyen d’ouvrir la connexion à la base de données le plus rarement possible, et que cette connexion puisse servir à toutes les requêtes de tout le monde.
J’ai retenu plusieurs solutions :

  • un object SqlConnection en Session: hors de question, cela multiplie les connexions à la base de données, et SQL Server pourrait même interdire des connexions lors des “pointes” de traffic.
  • un object SqlConnection ouvert depuis global.asa: le gérer d’un point de vue requête ? même problème que précédement. Point de vue application ? Ca peut être une idée. Si je veux que ma connexion ne se fasse que rarement, ce n’est pas non plus pour la garder ouverte même quand personne n’utilise le site. D’où une 3e solution:
  • gérer le SqlConnection dans un object en Cache, disons avec une durée de vie de 10 minutes, et qu’il coupe la connexion lors de sa destruction. Ca peut éviter de garder une connexion ouverte inutilement.

Si vous connaissez des exemples, si vous avez des remarques, des suggestions, des insultes, des petites amies à partager (non, j’ai pas dit votre mère), je suis preneur

Merci d’avance.

Zut, j’ai toujours pensé qu’on ouvrait une connexion seuleument avant de lancer une requête, et de la fermer le plus rapidement possible…

On m’aurait menti ?

Enfin moi je fais comme ça :
Chaine de connexion dans le Web.Config, et fonction globale qui s’occupe de créer l’objet xConnection sans l’ouvrir.

Je n’ai jamais pratiqué ca avec ASP mais généralement sur de gros sites Webs en PHP ou en Java on utilise des pools de connections que tes threads vont se partager par la suite.

Google est ton ami pour en savoir plus sur le sujet.

La MSDN, y’a que ça de vrai !

Pfff Man y a que ca de vrai

Koubiak pour son bon commentaire

[quote]Zut, j’ai toujours pensé qu’on ouvrait une connexion seuleument avant de lancer une requête, et de la fermer le plus rapidement possible…

On m’aurait menti ?

Enfin moi je fais comme ça :
Chaine de connexion dans le Web.Config, et fonction globale qui s’occupe de créer l’objet xConnection sans l’ouvrir.[/quote]Non, on t’as pas menti. Le pool de connection est géré automatiquement par le Client SQL. Donc, comme l’indique le lien a xentyr, le meilleur moyen, c’est d’ouvrir la connexion le plus tard possible, et de la refermer le plus tôt possible, et de laisser le systeme gérer son pool.

[quote]Non, on t’as pas menti. Le pool de connection est géré automatiquement par le Client SQL. Donc, comme l’indique le lien a xentyr, le meilleur moyen, c’est d’ouvrir la connexion le plus tard possible, et de la refermer le plus tôt possible, et de laisser le systeme gérer son pool.[/quote]Bien, étant persuadé que les pools de connexions se géraient via une méthode obscure, j’ai été surpris de savoir qu’ils l’étaient automatiquement.
Ma chaîne de connexion étant unique, à part quelques settings en plus dans ma chaîne, je n’ai donc rien à faire à part créer des objects SqlConnection aux bons endroits.

Juste une petite interface de plus pour gérer les compteurs de perfs et vérifier que mes connections “flottent” comme il le faudrait

Merci encore.

Avec quelques exemples qui vont bien, et de bonnes explications tout va bien.
Le fait est que je remarque qu’avec ASP premier du nom, j’ai pris vraiment de sales habitudes !

Quand je relis ce que j’ai dit plus haut concernant les solutions possibles, ça me fait maintenant doucement rire…

Ceci dit, en ASP classique, c’était pareil…

[quote]Ceci dit, en ASP classique, c’était pareil…[/quote]Oui je m’en rends compte maintenant.
Par contre, je faisais de l’ASP classique sur des vieux IIS4, NT4, et ils étaient pas vraiment à jour: je doute que le pooling était déjà en place.

S’il l’était, je ne le savais pas