Les pièges de l'appel d'une méthode statique depuis ASMX

Question

Je voudrais savoir s'il existe des pièges à appeler une méthode statique à partir d'un service web ASP.NET.

    internal static object SelectScalar(String commandText, DataBaseEnum dataBase)
    {
        SqlConnection sqlc = new SqlConnection(AuthDbConnection.GetDatabaseConnectionString());
        object returnval=null;
        if (sqlc!=null)
        {
            SqlCommand sqlcmd = sqlc.CreateCommand();
            sqlcmd.CommandText = commandText;
            sqlc.Open();
            returnval = sqlcmd.ExecuteScalar();
        }
        return returnval;
    }

Donc, par exemple, la méthode ci-dessus; y a-t-il des pièges lorsque plusieurs méthodes web et plusieurs clients appellent cette méthode en même temps (disons, 1000 appels à une méthode web qui appelle cette fonction)?

Answer 1

La chose à savoir est lorsque les membres statiques changent d'état qui est accessible à d'autres threads dans le domaine d'application. Dans ces cas, vous devez prendre les mesures appropriées pour que cela se fasse de manière ordonnée.

Votre méthode n'affecte aucun état en dehors d'elle-même (tout est local) donc vous êtes OK.

---

Comme l'ont noté duffymo et nader, vous devriez disposer de votre connexion comme vous devriez disposer de tout objet qui implémente IDisposable.

Answer 2

Je ne sais pas si le C# est comme Java, mais ouvrir une connexion SQL et ne pas la fermer avant de quitter la méthode ne me semble pas être une bonne idée. Le GC va le nettoyer une fois qu'il sortira de la portée, mais ce n'est pas la même chose que de fermer la connexion en Java.

L'idiome en Java exigerait de fermer la connexion dans un bloc finally. À moins d'être certain que la classe C# ne nécessite pas une telle chose, je vérifierais cela.

Vous le découvrirez assez rapidement - des milliers d'appels web épuiseront rapidement le nombre de connexions disponibles s'ils sont rares.

Une autre chose à vérifier : ouvrir des connexions de cette manière est coûteux en Java, donc elles sont généralement mises en pool. Le pooling de connexions est-il également fait en C# ? Est-ce inefficace de continuer à ouvrir et fermer une connexion à la base de données ? Pourriez-vous accomplir la même chose avec une connexion statique et partagée ? Si vous choisissez cette voie, peut-être que des problèmes de threading entrent en jeu.

Answer 3

Étant donné que vous créez une nouvelle SqlConnection, vous devez la disposer sinon la connexion ne se fermera pas. Consultez MSDN pour les directives d'utilisation.

Le fait que ce soit une méthode statique ne semble pas être un problème puisque vous ne mettez pas à jour un état partagé (variables globales).

ÉDITER : À ma connaissance, les "pièges" des méthodes statiques dans les services web sont les mêmes que dans n'importe quelle autre application. La seule chose à garder à l'esprit est qu'un service web est un serveur censé fonctionner de manière fiable pendant une longue période. Ainsi, les problèmes potentiels à long terme (fuites de mémoire, épuisement des connexions de base de données, etc.) sont plus significatifs que pour d'autres applications qui s'exécutent sur une période beaucoup plus courte.