Un service WCF sans état peut-il bénéficier du pool de connexions de base de données intégré?

Question

Je comprends qu'une application .NET typique qui accède à une base de données (n SQL Server) n'a rien à faire en particulier pour bénéficier du regroupement de connexions. Même si une application ouvre et ferme plusieurs fois les connexions à la base de données, elles sont mises en pool par le framework (en supposant que les éléments tels que les informations d'identification ne changent pas d'appel en appel). Mon scénario d'utilisation semble être un peu différent. Lorsque mon service est instancié, il ouvre une connexion à la base de données une fois, fonctionne, ferme la connexion et renvoie le résultat. Ensuite, il est détruit par le WCF, et le prochain appel entrant crée une nouvelle instance du service. En d'autres termes, mon service est instancié par appel client, comme dans [ServiceBehavior (InstanceContextMode = InstanceContextMode.PerCall)]. Le service accède à une base de données SQL Server 2008. J'utilise .NET Framework 3.5 SP1. Le regroupement de connexions fonctionne-t-il toujours dans ce scénario ou dois-je lancer mon propre pool de connexions sous la forme d'un singleton ou d'un autre moyen (IInstanceContextProvider?). Je préfère éviter de réinventer la roue, si possible.

Answer 1

L'application WCF classique qui accède à une base de données (n SQL Server) n'a rien à faire en particulier pour bénéficier du regroupement de connexions. Même si une application ouvre et ferme plusieurs fois les connexions à la base de données, elles sont mises en pool par le framework (en supposant que les éléments tels que les informations d'identification ne changent pas d'appel en appel).

Le modèle d'instance de service crée et supprime une instance de votre classe, et non un domaine entier. Le pool de connexion SqlClient est par AppDomain, vous recevrez donc votre repas gratuit.

Answer 2

Même s'il s'agit d'un ancien article, je pense qu'il est important d'y ajouter.

Le regroupement de connexions de base de données ADO.NET ne fonctionne PAS dans les services WCF par appel si vous suivez le scénario type (instanciation d'objets ADO.NET dans l'objet de service).

Bien que je comprenne la théorie et les arguments ci-dessus, ils ne sont que la théorie. Une simple application de formulaire Windows qui passe par l'étape ouvrir, interroger, fermer plusieurs fois vous montrera que le premier appel Open() prend assez de temps, par exemple 2 ou 3 secondes, et que les appels et requêtes suivants sont rapides - l'effet du regroupement de connexions.

Si vous mettez du code identique dans un service WCF par appel, vous obtenez le délai de 2 à 3 secondes sur EVERY CALL, le premier appel et tous les appels suivants. Conclusion - Le regroupement de connexions de base de données ADO.NET ne fonctionne PAS dans les services WCF par appel si vous effectuez l'instanciation ADO typique dans le service.

Vous devez instancier des objets ADO dans un hôte de service personnalisé et ajouter un code de synchronisation approprié si vous en avez besoin, ou vivre sans regroupement de connexions à la base de données.