Wie verhindere ich, dass auf statische Elementvariablen in IIS jeweils mehr als eine Anforderung zugegriffen wird?

Question

Ich habe Probleme damit zu verstehen, wie IIS statische Variablen in seinen Threads behandelt. Mein Verständnis war immer, dass, wenn IIS 4 Worker-Prozesse hat, es 4 Anfragen gleichzeitig behandeln kann und dass es das gleiche wäre, als hätte man 4 separate Threads, die die Website ausführen. Alle statischen Variablen würden in jedem einzelnen Thread bestehen bleiben. Der Grund, warum ich ein wenig verwirrt bin, ist, dass ich einen Bereich habe, den ich gemacht habe, der Verbindungen und Caching-Transaktionen verwaltet. Wenn ich die App teste, merke ich keine Probleme, aber nachdem ich sie kompiliert und gleichzeitig von zwei verschiedenen Orten aus getroffen habe, scheint mir eine Art von Konflikt zu entstehen. Wenn diese Arbeitsprozesse getrennt sind, warum sollte das dann sein? Können mehrere Anfragen gleichzeitig in einem einzelnen Worker-Thread bearbeitet werden? Dies ist enorm wichtig, da eindeutige IDs in diesen statischen Membern enthalten sind, um die Eskalation der Objekte zu verwalten, die diese Funktionen verwalten, und es scheint, dass sie versuchen, auf dasselbe Objekt zuzugreifen.

Ich führe dies auf Vista IIS-Server auf einem x64-Rechner.

EDIT

Bei Werten, die auf einer einzigen Anforderung durch das Gewinde müssen bestehen bleiben, habe ich diese Werte in Web.HttpContext.Current.Items, die den Trick zu tun scheint.

<ThreadStatic()> kann verwendet werden, ist aber möglicherweise während des gesamten Anforderungsprozesses nicht verfügbar. In einem Modul, das ich habe, wird nur auf eine Variable verwendet, um anzuzeigen, wenn dieser Thread die Einstellungen für den Caching-Server bereits geladen hat. Wenn dies der Fall ist, ist das Profil (nicht asp.net) bereit, Daten vom Caching-Server abzurufen.

Answer 1

Erstes Konzept zu ändern: Wenn Sie ASP.NET verwenden, sind sie ASP.NET-Threads, nicht IIS-Threads.

Zweitens ist dies ein .NET-Problem. statische Variablen sind im gesamten AppDomain in .NET geteilt. Da Sie pro IIS-Anwendung (mehr oder weniger) eine AppDomain haben, bedeutet dies, dass Ihre statischen Variablen für alle Worker-Threads in der Anwendung freigegeben werden.

Es wird viel mehr als vier Threads geben, und alle teilen die gleichen Variablen, was bedeutet, dass Sie entweder sperren müssen, oder Sie müssen keine statischen Variablen verwenden.

Was auch immer Ihr Verständnis war, ich schlage vor, dass Sie zurückgehen und herausfinden, woher Sie dieses Verständnis haben; dann aktualisieren Sie es, weil es nicht viel mit ASP.NET zu tun hat.

---

EDIT: Das Thema hat sich geändert, so dass die Antwort, die ich werde ein wenig ändern.

Sie müssen den Zugriff auf diese Variablen verriegeln. Alternativ sollten Sie eine Neubewertung Ihres Designs in Betracht ziehen. Ihr Entwurf hat offensichtlich ein anderes Modell für den Zugang zur Statik angenommen. Diese Annahme hat sich als nicht richtig herausgestellt. Es ist möglich, dass diese Annahme in Ihrem Design kaskadiert hat. Sie sollten Ihr Design im Lichte der Realität neu bewerten.

Answer 2

Jeder Arbeitsprozess wird in seiner eigenen AppDomain ausgeführt, sodass jeder WP über eine eigene Instanz einer statischen Variablen verfügt.

In der Antwort hier schlägt es vor, dass die AppDomain über WPs geteilt wird, die falsch ist.

Sie sollten jedoch das .NET-Verbindungspooling verwenden, und Sie sollten die using (IDisposable) {} -Methode untersuchen, um Ihre Verbindungen zu überprüfen.