6 votes

SqlConnection avec programmation parallèle

Voici mon code existant qui sauvegarde des données dans plusieurs tableaux.

using (SqlConnection conn = new SqlConnection("myConnString"))
{
   DoWork1(conn);
   DoWork2(conc);
   DoWork3(conn);
}

Afin d'accélérer mon code, j'ai essayé d'obtenir le support de .net TPL et j'ai réorganisé mon code comme suit

using (SqlConnection conn = new SqlConnection("myConnString"))
{
   ParallelOptions pw = new ParallelOptions();
   pw.MaxDegreeOfParallelism = Environment.ProcessorCount;

   Parallel.Invoke(pw,()=> DoWork1(conn),()=> DoWork2(conc),()=> DoWork3(conn));
} 

Mais je reçois une exception d'erreur fatale de connexion interne de la méthode ExecuteNonQuery() dans ma couche d'accès aux données. Mon approche parallèle est-elle mauvaise ?

9voto

Jon Skeet Points 692016

Eh bien, il y a des moyens de le faire potentiellement être mis en œuvre en utilisant MARS - mais je suggère une approche différente. (Je ne sais pas si MARS prend en charge l'utilisation de la même connexion à travers plusieurs threads, même s'il permet plusieurs opérations simultanées).

Au lieu d'essayer de réutiliser une connexion dans toutes les tâches parallèles, faites en sorte que chaque tâche ouvre (et ferme) une connexion pour elle-même, et laissez la mise en commun des connexions gérer l'efficacité de tout cela. C'est la meilleure pratique générale en .NET, que vous utilisiez le parallélisme ou non : ouvrez la connexion, effectuez un travail, fermez la connexion.

0voto

user2849221 Points 53

Je n'ai pas la réputation de commenter mais il semble que je puisse répondre. C'est un peu étrange De toute façon, mon commentaire était que les tables temporaires sont par connexion, donc ouvrir une nouvelle connexion signifie que vous ne pouvez pas voir les tables temporaires créées par l'autre tâche.

Les tables temporaires globales pourraient être la solution mais vous devez soit a) utiliser une seule table temporaire globale et partitionner les données en utilisant une clé quelconque b) utiliser des tables portant un nom unique, ce qui implique un langage SQL dynamique.

C'est un peu le bordel, vraiment

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X