2010-04-07 4 views
1

J'ai une méthode qui tente de mettre à jour une base de données SQL Server dans une application ASP.NET. Si la mise à jour échoue, elle attrape l'exception, puis met en file d'attente la mise à jour dans MSMQ, puis crée un nouveau thread qui annule la mise à jour en attente et réessaie. Lorsque le thread démarre, il ne parvient pas à ouvrir une connexion à la base de données car il tente de se connecter à l'aide du service réseau en tant que connexion. La connexion sql utilise l'authentification Windows et fonctionnera en dehors du thread. Si je mets un point d'arrêt dans le code qui s'exécute dans le nouveau thread et vérifie Thread.CurrentPrincipal, il montre l'identité comme étant l'utilisateur correct. Pourquoi la connexion sql tente-t-elle d'être ouverte par le compte Service réseau?Connexions C# Threading et Sql

Je peux élaborer plus loin est nécessaire.

Merci.

+0

Comment démarrez-vous le nouveau thread? – Cocowalla

+0

Thread thread = nouveau thread (délégué); thread.Start(); –

Répondre

1

J'ai découvert une solution encore plus élégante qui ne nécessite pas les modifications du fichier aspnet.config.

// get the current WindowIdentity of the main thread 
var currentIdentity = WindowsIdentity.GetCurrent(); 

Thread thread; 
thread = new Thread(() => 
      { 
       // using lambda closure, access the current identity 
       // inside the background thread scope and call Impersonate 
       var context = currentIdentity.Impersonate(); 

       // do multi-threaded stuff 


       // undo the impersonation before leaving the thread 
       context.Undo(); 
      }) 
     { 
      Name = "BackgroundThread", 
      IsBackground = true 
     }; 
thread.Start(); 
0

Je pense que vous devez vérifier l'identité du pool d'applications sous lequel s'exécute le site Web dans IIS - est-il défini sur Service réseau?

En outre, quel paramètre d'emprunt d'identité est dans votre fichier web.config? Vérifiez si vous personnifiez l'utilisateur actuel, un utilisateur spécifique ou aucun utilisateur (et que l'identité du pool d'applications est donc utilisée).

Il serait utile que vous ayez aussi posté votre chaîne de connexion.

+0

Le pool d'applications utilise l'identité du service réseau par défaut. Dans le fichier web.config, l'identité a impersonate = "true" et nous usurons l'identité d'un compte spécifique. La chaîne de connexion utilise Trusted_Connection = yes; data source = myDataSource; J'ai trouvé cet article: http://support.microsoft.com/kb/326606 qui pourrait être similaire. Je n'utilise pas l'état de session, mais cet article indique que l'état de session utilise un thread d'arrière-plan pour se connecter à la base de données SQL Server et ne peut pas se connecter car le thread s'exécute sous le processus de travail ASP.NET. –

1

je me suis dit qu'il en se basant sur ce fil: http://bytes.com/topic/asp-net/answers/597465-simple-thread-issue

je devais ajouter à la partie supérieure du bloc de code du fil:

((WindowsIdentity)Thread.CurrentPrincipal.Identity).Impersonate(); 
+0

En fait, cela ne fonctionnera pas non plus, puisque j'ai vérifié les informations d'identification que la base de données utilisait pour effectuer les appels à partir du thread principal et du thread d'arrière-plan. Il s'avère que ce qui précède ne faisait que me travestir (l'utilisateur connecté), et non le compte de service spécifié dans le fichier web.config. Depuis que j'ai eu accès à la base de données, l'appel a été réussi, mais quand cela va à la production, ce ne sera pas le cas. o maintenant je regarde ExecutionContext et voir si cela m'achète quelque chose .. –

0

Ce lien est là où je trouve la réponse: http://www.leastprivilege.com/WhatIsAspnetconfig.aspx

Voici le panneton de l'info:

<configuration> 
    <runtime> 
    <legacyUnhandledExceptionPolicy enabled="false" /> 
    <SymbolReadingPolicy enabled="1" /> 

    <legacyImpersonationPolicy enabled="false" /> 
    <alwaysFlowImpersonationPolicy enabled="true" /> 
    </runtime> 
<configuration>