Superviser le nombre de connexions

le code du listing 1 pour
ouvrir et fermer les connexions avec
l’application Web. La routine du renvoi
A crée, ouvre et exécute des requêtes
sur 110 nouveaux objets SqlConnection
– 10 de plus que la taille du pool
par défaut. Il faut fermer et mettre au
rebut toutes ces connexions avant de
quitter la routine. Faute de quoi, les
objets SqlConnection se retrouvent orphelins
en même temps que les
connexions poolées associées. Le mécanisme
de pooling ADO.NET (appelé
aussi le pooler) ferme les connexions à 
la base de données, mais ne ferme pas
les connexions poolées. Je définis la
taille du connection pool à  10 pour
que le programme échoue plus rapidement
– s’il doit échouer. En principe,
10 connexions représentent beaucoup
pour une requête qui s’exécute aussi
rapidement que celle-ci. Beaucoup de
développeurs utilisent des sites Web
très actifs qui utilisent moins de 5
connexions pour traiter des centaines
de milliers de hits par jour.
La routine du renvoi A crée des objets
SqlConnection et SqlCommand,
définit le CommandText, et ouvre la
connexion. Après quoi, le code du renvoi
B détermine s’il faut utiliser
CommandBehavior. CloseConnection
quand on exécute le DataReader, selon
quel CheckBox contrôle l’utilisateur
sélectionné sur le formulaire Web.
Dans le code du renvoi C, je précise
s’il faut lier le rowset DataReader à  un DataGrid ou faire une boucle dans le rowset. Le code du
renvoi C teste ce qui arrive quand on atteint la fin du rowset
qui a été retransmis à  partir du data provider par l’intermédiaire
du DataReader.
Maintenant, j’utilise le code du renvoi D pour indiquer
s’il faut fermer manuellement la connexion ou laisser ce soin
à  une autre opération comme le data binding. A dire vrai, il
est généralement plus sûr de fermer la connexion manuellement
pour être certain qu’elle ne sera pas orpheline.
Si le code fonctionne jusqu’à  ce point, c’est le signe que
j’ai correctement ouvert et fermé 110 connexions. Mais si
quelque chose se passe mal, les gestionnaires d’exceptions
dans le code du renvoi E intercepteront l’exception (généralement
un Timeout) comme une InvalidOperationException,
qui est la manière dont ADO.NET réagit quand le
connection pool est plein.
Le tableau 1 récapitule comment les diverses options
permettent à  la routine de fonctionner ou d’échouer. Notons
que si vous ne définissez pas l’option CommandBehavior.
CloseConnection, vos opérations risquent d’échouer –
même si vous utilisez un contrôle bound. L’opération
échoue même quand vous utilisez cette option si vous n’utilisez
pas un contrôle bound complexe ou si vous ne fermez
pas manuellement SqlDataAdapter ou SqlConnection.
Quand j’ai fini de travailler avec ces applications
exemples, j’avais généré plus de 1 000 connexions poolées –
toutes orphelines. Bien que le comptage de SQL Server User
Connections ait été de 0, environ 4 connection pools sont
restés à  la traîne. Les pools orphelins n’ont disparu que
quand j’ai réinitialisé le système.
Les applications exemples que j’ai utilisées pour ce test
incluent des routines qui utilisent le DataAdapter pour renvoyer
des lignes. A moins de gérer manuellement les
connexions, le DataAdapter ouvre et ferme correctement
l’objet SqlConnection, donc vous ne risquez pas de rencontrer
des connection pools orphelins. En revanche, si votre
application utilise à  la fois un DataReader et un DataAdapter,
vous constaterez peut-être que le DataAdapter ne peut pas
appliquer une requête à  une connexion si celle-ci est associée
à  un DataReader non fermé.