Le gardien du .Net Connection pool

Les participants aux groupes de
discussion par e-mail se plaignent souvent du fait que les applications
semblent fonctionner lors des tests
mais échouent en production. Ils signalent
parfois que leurs applications
s’arrêtent ou saturent quand 100
clients environ sont connectés. Rappelons
que le nombre de connexions
par défaut dans un pool est de 100. Si
l’on essaie d’ouvrir plus de 100
connexions à  partir d’un pool, ADO.
NET met en file d’attente la demande
de connexion de votre application jusqu’à 
ce qu’une connexion soit libre.
L’application (et ses utilisateurs) voit
cela comme un retard dans l’obtention
de la page Web ou comme un blocage
de l’application. Voyons donc comment
ce problème survient.
Dans ADO.NET, le SqlClient .NET
Data Provider propose deux techniques
pour ouvrir et gérer les connexions.
Premièrement, quand vous
devez gérer la connexion manuellement,
vous pouvez utiliser l’objet
DataReader. Ce faisant, votre code
construit un objet SqlConnection,
définit la propriété ConnectionString,
et utilise la méthode Open pour ouvrir
une connexion. Quand le code en a fini
avec le DataReader, vous fermez la
SqlConnection avant que l’objet
SqlConnection soit hors de portée .
Pour traiter l’ensemble de lignes, vous
pouvez transmettre le DataReader à 
une autre routine de l’application,
mais il faudra quand même vous assurer
que le DataReader et sa connexion
sont fermés. Si vous ne fermez pas le
SqlConnection, votre code « laisse
fuir » une connexion avec chaque opération,
donc le pool accumule les
connexions, parfois jusqu’au débordement.
Contrairement à  ADO et Visual
Basic (VB) 6.0, le collecteur de .NET ne
ferme pas la SqlConnection et fait le
nettoyage. Le listing 1, que j’examinerai
plus loin, montre comment j’ai ouvert
une connexion et généré un
DataReader pour renvoyer l’ensemble
de lignes à  partir d’une simple requête
pour stresser le connection pool.
Vous risquez aussi des problèmes
quand vous utilisez l’objet DataAdapter.
Les méthodes DataAdapter Fill et
Update ouvrent automatiquement
la connexion de l’objet DataAdapter et
la ferment au terme de l’opération
d’I/O des données. Cependant, si la
connexion est déjà  ouverte quand la
méthode Fill ou Update est exécutée,
ADO.NET ne ferme pas le SqlConnection
à  la fin de la méthode. C’est encore
une autre occasion de laisser fuir
une connexion.
En outre, vous pouvez aussi utiliser
ADO basé sur COM pour créer une
connexion à  partir d’une application
.NET. ADO poole ses connexions de la
même manière que le fait ADO.NET
mais ne vous donne pas un moyen de
surveiller le pool à  partir de votre application,
comme vous le pouvez
quand vous utilisez le SqlClient ADO.
NET Provider.