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 sécurité cloud-native
L’État des lieux de la sécurité cloud-native vous offre une analyse complète des problématiques, des tendances et des priorités qui sous-tendent les pratiques de sécurité cloud-native dans le monde entier. Une lecture indispensable pour renforcer votre stratégie de sécurité dans le cloud. Une mine d’infos exclusives pour élaborer votre stratégie de sécurité cloud-native.
