expertenaustausch > microsoft.* > microsoft.german.entwickler.dotnet.asp

Mirco Kaffsach (07.11.2008, 14:22)
Hi @all,

ich habe da mal eine Frage bezüglich Multithreading und Zugriffe auf den
HttpContext.
Ich habe den folgenden Code der weiter unten steht.

Weiterhin nehmen wir einfach der Einfachheithalber mal an die anderen
Thread{Nummer}Method Methoden würden das gleiche tun.
Dieser Code ist in einer DLL drin, auf die aus einer WebAnwendung verwiesen
wird. Soll heissen, das ich im Code an der Stelle: thread1.Start(); den
HttpContext.Current noch zur Verfügung habe.

Innerhalb der Methode "Thread1Method()" habe ich den HttpContext.Current
nicht mehr zur Verfügung und mein Code knallt hin, da es eine Null Reference
Exception gibt.

Gibt es irgendeine Möglichkeit, das der Thread den Context so "erbt" das er
in der Methode "Thread1Method()" den HttpContext.Current noch hat und dort
lesend auf z.B. den Cache zugreifen kann?

Schonmal Danke, Mirco
Thread thread1 = new Thread(this.Thread1Method);
Thread thread2 = new Thread(this.Thread2Method);
Thread thread3 = new Thread(this.Thread3Method);
Thread thread4 = new Thread(this.Thread4Method);

thread1.Start();
thread2.Start();
thread3.Start();
thread4.Start();

thread1.Join(5000);
thread2.Join(5000);
thread3.Join(5000);
thread4.Join(5000);

public void Thread1Method()
{
string test =
System.Web.HttpContext.Current.Cache["GeCachetesIrgendwas"].ToString();
}
Thomas Bandt (07.11.2008, 16:17)
Mirco Kaffsach schrieb:
> Gibt es irgendeine Möglichkeit, das der Thread den Context so "erbt" das
> er in der Methode "Thread1Method()" den HttpContext.Current noch hat und
> dort lesend auf z.B. den Cache zugreifen kann?


Freitag? :-)

public void Thread1Method(HttpContext context)
{
}
Mirco Kaffsach (10.11.2008, 10:28)
Hmm neee nicht Freitag,

das will und kann ich nicht soo weitergeben. Ich hätte gerne das der Thread
ansich den Context hat und ich den nicht noch explizit an die Methode mit
übergeben muss.

Geht das denn irgendwie? Im Thread Objekt habe ich ein ExecutionContext
gefunden, aber den kann ich nur auslesen und nicht setzen.

LG Mirco

"Thomas Bandt" <no> schrieb im Newsbeitrag
news:1012
[..]
Thomas Bandt (10.11.2008, 11:25)
Mirco Kaffsach schrieb:
> Hmm neee nicht Freitag,
> das will und kann ich nicht soo weitergeben. Ich hätte gerne das der
> Thread ansich den Context hat und ich den nicht noch explizit an die
> Methode mit übergeben muss.


Mit welcher Begründung?

> Geht das denn irgendwie? Im Thread Objekt habe ich ein ExecutionContext
> gefunden, aber den kann ich nur auslesen und nicht setzen.


Warum startest du denn den Thread - weil du etwas unabhängig
von der aktuellen Anforderung ausführen willst. Also läuft
der Thread auch losgekoppelt vom aktuellen Kontext - er kann
damit überhaupt nicht auf ihn zugreifen.
Mirco Kaffsach (10.11.2008, 15:52)
Hi,

> Warum startest du denn den Thread - weil du etwas unabhängig
> von der aktuellen Anforderung ausführen willst.


neee, also ich habe 5 Dinge die gleichzeitig laufen können, da manche nur
lesend auf Session Variablen zugreifen, bzw. einige Methoden Dinge aus dem
Cache lesen und dann zur weiterverarbeitung nutzen. Also starte ich Threads,
damit die parallel laufen, aber dennoch brauchen sie den Kontext. Für mich
bedeutet es nicht das Dinge die in Threads ausgelagert werden nichts mit dem
Context zu tun haben.

Außerdem möchte ich es halt vermeiden das ich gewisse Dinge mitgebe, da die
Funktion auch in STA Webs genutzt wird und die Methoden dann ja ohne
Probleme auf den Context zugreifen können. Wenn ich jetzt den Context
mitgebe, dann müsste ich die Funktion überladen, oder aber in allen Webs die
diese Funktion nutzen schauen und bei dem Aufruf der Methode den Context
mitgeben.

Gibt es denn keine Möglichkeit dem Thread zu sagen das er den Context erben
soll?

Mirco

"Thomas Bandt" <no> schrieb im Newsbeitrag
news:5080
[..]
Andreas Heyer (10.11.2008, 23:51)
"Mirco Kaffsach" <someone> wrote:
> Gibt es denn keine Möglichkeit dem Thread zu sagen das er den
> Context erben soll?


Nun ja, wahrscheinlich könnte man über Reflektion die
HttpContext.Current-Funktion aus der Webanwendung statt aus
deiner DLL aufrufen. Nur warum sollte man das tun, wo es doch
viel einfacher ist, seiner Threadfunktion die passende Referenz
mitzugeben?

MfG
Andreas
Andreas Heyer (11.11.2008, 07:30)
Ahhh, das war natürlich Unsinn!!! Ich hatte das mit getrennten
Exe verwechselt, wo natürlich jede ihre eigenen Instanzdaten aus
einer fremden DLL bekommt, nur der Code wird geteilt. Bei dir
läuft natürlich deine DLL in der Web-App und hat Zugriff auf die
gleichen statischen Daten.

Es wird wohl so sein, dass HttpContext.Current die Thread-ID
prüft. Dies ist auch logisch, denn ASP.NET verarbeitet die
Anfrage in *einem* Thread aus einem Pool, es liegt also eine
1:1-Relation zwischen Anfrage/Context und Thread vor. Current
holt demzufolge den HttpContext aus dem Slot für den
verarbeitenden Thread. Deine eigenen Threads sind aber ASP.NET
unbekannt, es gibt also keinen Slot für sie.
Dieses Verhalten ist auch logisch, denn da deine Threads
unabhängig von dem die Anfrage verarbeitenden Thread sind, kann
der Context schon lange wieder ungültig sein, während du noch
damit arbeiten willst. Die Laufzeitumgebung kann nicht wissen,
dass du (hoffentlich) deine Workerthreads vor der Beendigung der
Webanfrage wieder mit dem ASP.NET-Pool-Thread joinst.

Sollte das nicht das Design deiner Web-App sein, so ist IMHO der
Zugriff auf den HttpContext gänzlich falsch.

MfG
Andreas
Ähnliche Themen