> Data > Nager dans le .Net Connection Pool

Nager dans le .Net Connection Pool

Data - Par iTPro.fr - Publié le 24 juin 2010
email

par par William Vaughn - Mis en ligne le 24/08/2004 - Publié en Décembre 2003

Concevez et configurez votre connection pool .NET en utilisant du bon sens, des requêtes ordinaires, et une poignée de propriétés SqlClient peu connues

En tant qu'instructeur et consultant en ADO.NET et Visual Basic (VB), on m'interroge souvent sur l'utilisation des pools de connexion d'ADO.NET...Ces questions viennent de clients, d'étudiants, de newsgroups et de serveurs de listes. Les questions posées sont du genre :

  • Comment puis-je activer et désactiver le connection pool ?
  • Combien de connexions sont déjà  dans le pool ?
  • ADO.NET et ADO semblent se bloquer après environ 100 connexions. Pourquoi ne peuvent-ils pas ouvrir davantage de connexions ?
  • Comment puis-je reconnaître l'utilisateur exécutant le code dans la chaîne de connexion sans épuiser rapidement les connexions ?
  • Comment puis-je m'assurer que seules les personnes autorisées ont accès à  la base de données et continuer à  tirer parti du connection pool ?
  • Comment puis-je partager une connexion commune entre différentes parties de mon application ?
Après avoir lu cet article, vous connaîtrez les réponses à  ces questions et à  beaucoup d'autres portant sur le connection-pool. J'explique comment connecter correctement les applications au serveur et, plus important, comment les en déconnecter quand le connection pool gère vos connexions. Dans un prochain article, je poursuivrai en expliquant comment superviser l'activité du mécanisme de connectionpooling (aussi appelé pooler) et comment être certain que l'application utilise le pooler correctement - de préférence avant qu'il ne déborde et n'endommage votre système.

Voilà  plus de 5 ans, Microsoft a introduit
les pooled connections pour tous
les drivers ODBC afin de traiter plusieurs
problèmes que les développeurs
résolvaient de leur côté. Les développeurs
voulaient réduire le coût d’établissement
ou de rétablissement d’une
connexion. C’était trop long, l’évolutivité
était limitée et on consommait
trop de connexions côté serveur. La
philosophie du pooling est que quand
une application ferme une connexion,
le handle de connexion revient à  un
pool géré par driver ou provider, où il
reste pendant un certain laps de temps
afin que l’application puisse le réutiliser.
Bien que cette approche ne soit
pas aussi importante dans les applications
client/serveur qui n’utilisent
qu’une connexion, elle est primordiale
quand on crée des applications COM+
ou Active Server Pages (ASP) middletier
de haute performance qui exécutent
des instances multiples de composants
qui pourraient en toute sécurité
réutiliser le même handle de
connexion.
Depuis la première version de
connection pooling, chaque version
d’ODBC l’a pris en charge par défaut.
SQL Server 2000 a résolu beaucoup
des premiers problèmes dont souffrait
le connection pooling et Microsoft l’a
inclus dans OLE DB et dans le .NET
Framework.

Téléchargez cette ressource

État des lieux de la réponse à incident de cybersécurité

État des lieux de la réponse à incident de cybersécurité

Les experts de Palo Alto Networks, Unit 42 et Forrester Research livrent dans ce webinaire exclusif leurs éclairages et stratégies en matière de réponses aux incidents. Bénéficiez d'un panorama complet du paysage actuel de la réponse aux incidents et de sa relation avec la continuité de l'activité, des défis auxquels font face les entreprises et des tendances majeures qui modèlent ce domaine. Un état des lieux précieux pour les décideurs et professionnels IT.

Data - Par iTPro.fr - Publié le 24 juin 2010