Gérer un grand nombre de nageurs

chaque connexion
juste avant qu’elle soit nécessaire et à 
la fermer le plus tôt possible – c’est la
stratégie du JIT (just-in-time). ADO.
NET est utile à  cet égard parce qu’il
ouvre les connexions automatiquement
quand on utilise la méthode
DataSet Fill ou Update. Si vous utilisez
un DataReader, vous devez ouvrir et
fermer la connexion vous-même.
Même si vous utilisez l’option CommandBehavior.
CloseConnection, vous
devez néanmoins fermer le Data-
Reader pour obtenir la fermeture de la
connexion associée. Contrairement à 
VB 6.0, aucun des langages .NET ne
peut garantir que votre connexion se
fermera quand un objet Connection
(tel que SqlConnection) se retrouvera
hors du domaine. Si la connexion est
encore ouverte, vous ne pouvez pas la
réutiliser. Si l’objet Connection est encore
ouvert quand il sort du domaine,
il est probablement perdu à  jamais. Par
exemple, le segment de code du listing
1 va « laisser fuir » une connexion
chaque fois que la procédure s’exécute
parce que la Connection n’est pas
fermée avant que la fonction qui crée l’objet Connection ne soit terminée.
Cette fuite se produit parce que le
code ne peut plus faire référence à 
l’objet Connection (qui possède la
pooled Connection) après qu’il sorte
du domaine et le ramasse-miettes .NET
ne nettoiera pas forcément ces objets
devenus orphelins. Bien que le code
du listing 1 fonctionne en VB 6.0 et
ADO basé sur COM, le code ne fonctionne
pas dans ADO.NET.
La performance de votre site Web
dépend beaucoup du comportement
de l’application quand toutes les
connexions disponibles sont en service.
Retenez ce conseil : vous pouvez
augmenter la valeur de l’argument de
la chaîne de connexion ConnectionTimeout
ou la propriété ConnectionTimeout
de l’objet Connection.
L’une de ces valeurs, ou les deux, permettent
de définir le laps de temps
pendant lequel ADO.NET attend
qu’une connexion soit libérée à  partir
du pool et mise à  disposition de votre
code. Si vous réglez la valeur trop haut,
le navigateur (ou client) risque de se
mettre en timeout et de déclencher
le System.InvalidOperationException
avant que vous ne soyez connecté. A
l’inverse, si la valeur est trop basse,
votre gestionnaire d’erreurs devra savoir
comment retenter la connexion –
peut-être après avoir invité le client à 
être patient pendant que votre application
traite d’autres requêtes.