Utiliser effectivement les connection pools

vous ouvrez et fermez.
Rappelons que les ressources limitantes
sont le nombre de connexions
qu’un pool peut traiter et le
nombre de connexions disponibles sur
le serveur. Comme je l’ai indiqué précédemment,
le nombre par défaut de
connexions qu’un pool peut traiter est
de 100 ; on peut définir un nombre supérieur
mais quand le nombre de
connexions dans le pool atteindra
cette valeur, le .NET Data Provider ne
créera plus de pooled connections.
Dans l’idéal, votre application devrait
utiliser une connexion momentanément
puis la restituer au pool pour que
d’autres instances puissent la partager.
Donc, 100 connexions par pool devraient
suffire amplement.
On peut laisser le .NET Data
Provider créer un nombre quelconque
de pools, toujours dans la limite du
nombre de connexions que SQL Server
autorise d’après votre licence ou le paramétrage
administrateur. Si certains
des composants sont susceptibles de
revendiquer des connexions dans un
pool très utilisé, il vaut mieux séparer
ces composants en créant deux pools
ou plus – un pour chaque opération
fonctionnelle. Une manière d’établir
cette séparation consiste à  définir le
nom de l’application dans le ConnectionString
avec une valeur unique pour
chaque pool que l’on veut voir créer
par le .NET Data Provider. Attention
toutefois car quand un pool déborde
(c’est-à -dire qu’on dépasse le nombre
défini de connexions), la performance
du composant s’effondre et vos clients
s’adressent à  d’autres sites.