Quelles sont les conséquences de ne pas fermer la connexion à la base de données après une erreur?

Question

J'ai une application qui cause beaucoup de maux de tête. C'est une application .NET qui se connecte à SQL Server 2005 via un service Web. Le programme a une grille qui est remplie par une procédure stockée qui s'exécute depuis longtemps et qui est susceptible d'expirer. Dans le cas où il expire et qu'une exception SqlException est levée, il n'y a pas de gestion d'exécution pour fermer la connexion.

Quelles sont les conséquences réelles de cette situation? Je pense que le framework ou SQL Server s'en charge probablement d'une façon ou d'une autre mais je ne suis pas sûr.

Ajout Le programme fonctionne toujours bien le matin, mais après environ une heure d'utilisation, il ne fonctionne pratiquement plus. Le problème n'est pas que je ne sais pas comment coder la connexion correctement. J'ai besoin de savoir si ces symptômes pourraient être traités par les connexions non fermées. C'est un gros problème de changer le code de production et je voudrais savoir qu'il est au moins possible que cela soit le problème.

Conclusion J'ai généré cette défaillance sur des centaines de connexions simultanées. Je n'ai jamais pu reproduire la condition d'échec dans l'environnement d'application. Les meilleures pratiques marquées répondent comme correctes. Merci tout le monde.

Answer 1

Depuis un SqlConnection ferme tout en se débarrassant i l'habitude d'utiliser cette syntaxe

using (SqlConnection conn = new SqlConnection()) 
{ 
    // SqlCode here 
} 

Answer 2

Il existe une limite de connexion; Si votre application se bloque fréquemment et ne ferme pas les connexions automatiquement, les nouvelles demandes de connexion seront refusées. Cela dit, les connexions expirent après un certain temps si elles ne sont pas fermées.

Answer 3

Vous pourriez manquer de connexions disponibles si cela arrive souvent assez, vous devez utiliser un partout où vous exécutez une commande pour fermer la connexion.

Answer 4

Le garbage collector finalisera éventuellement votre objet de connexion ouvert, mais vous ne saurez pas quand le GC reviendra la prochaine fois. Jusque-là, vous pourriez manquer de connexions dans votre piscine si vous avez beaucoup de trafic ou s'il s'agit d'un serveur sql partagé. Pourquoi ne pas le jeter dans la section finale de votre bloc try/catch?

finally 
{ 
    if (cn != null) 
    { 
     cn.Dispose(); 
     cn = null; 
    } 
} 

Cela doit être fait dans la méthode de service Web évidemment.

Answer 5

try 
{ 
    sqlCommandObject.Execute(); // this line will throw a timeout exception 
} 
finally 
{ 
    sqlConnectionObject.Close(); // this will execute no matter what happens 
} 

Answer 6

Si l'application cesse de fonctionner au bout d'une heure environ, cela pourrait être causé par des connexions non fermées/éliminées.

Answer 7

Voilà pourquoi le mot-clé « en utilisant » est si important lors de l'utilisation ADO.Net

using (SqlConnection conn = new SqlConnection()) 
{ 
    ... 
} 

Cela force un type de Garbage Collection déterministe sur l'objet ADO.Net en utilisant l'interface IDispose.

La plupart des codes de base de données utilisent un grand nombre de clauses 'using' imbriquées à cette fin.