Nager dans le .Net Connection Pool

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.