ASP.NET: Implémentation correcte des appels d'API imbriqués à l'aide du pool de connexions et des transactions imbriquées

Question

J'ai besoin de connaître la meilleure façon de procéder. J'ai des API de niveau métier imbriquées (disons niveau 1 & niveau 2). L1 doit appeler L2. Les deux API utilisent la couche de base de données directement à leurs propres niveaux d'imbrication.

Maintenant, dans la couche de base de données, je vais chercher la connexion db de la piscine à chaque fois comme suit:

SqlConnection conn = new SqlConnection(connString); 
    conn.Open(); 

1. Est-il approprié de chercher la connexion db à chaque fois sur chaque appel de niveau DB au dessus? Je sais qu'il retournera une connexion du pool de connexions ASP.NET.

2. Cependant, ne serait-il pas préférable de maintenir la même connexion DB pendant les appels imbriqués (ou tout au long de la durée de vie de la requête http actuelle)?

3. Est-ce que l'extraction d'une connexion à partir du pool provoquera chaque fois des problèmes avec les TransactionScopes imbriquées?

Answer 1

Réponse à # 1 Il est ok, mais si votre système est vraiment occupé que vous devrez le paramètre de connexion max dans votre chaîne de connexion. Idéalement, (au moins comme je le fais: - Une connexion pour le cycle de réponse aux demandes.)

2,3 Selon la façon dont vous implémentez les deux couches, et oui les transactions poseront problème si vous n'avez qu'une seule connexion que les deux couches utilisent. Je suppose que les deux couches ne sont pas vraiment "connectées" en ce sens que vous n'avez pas besoin de transactions pour travailler sur ces couches. Si c'est le cas, je suivrai la route que vous avez.