2016-06-08 24 views
0

Ich arbeite derzeit an einem System, das Aufrufe an einen externen Dienst ausführt und einige der Daten in der HttpContext.Current.Items-Auflistung für die Leistung zwischenspeichert. Die Daten können sich ziemlich regelmäßig ändern und es ist benutzerempfindlich, weshalb wir es momentan nur für die Dauer der aktuellen HttpRequest speichern.Zugreifen auf in HttpContext.Current.Items über Threads gespeicherte Daten

Beispiel:

if (HttpContext.Current.Items[cacheKey] != null) 
{ 
    LogHelper.Debug<ExampleService>("[- CACHED RESULT -] GetUser({0})",() => email); 
    return (ExampleUser)HttpContext.Current.Items[cacheKey]; 
} 

using (var client = new UserServiceClient()) 
{ 
    using (new OperationContextScope(client.InnerChannel)) 
    { 
     LogHelper.Debug<ExampleService>("GetUser({0})",() => email); 
     exampleUser = svc.GetUser(email); 
     HttpContext.Current.Items.Add(cacheKey, exampleUser); 
    } 
} 

In meiner lokalen Umgebung verhält sich dies wie erwartet und meistens tut auch in der Inszenierung, wo das gleiche Gewinde für die Dauer der Anforderung in der Produktion ist jedoch verwendet wird dies nicht der Fall und es gibt immer noch mehrere Anrufe an den externen Dienst in der gleichen Anfrage. Dies geht aus den Protokollen hervor, die zeigen, dass der Wert in HttpContext.Current.Items[cacheKey] nicht zurückgegeben wird, wenn die Thread-ID nicht mit der ursprünglichen Anfrage übereinstimmt.

Dies bedeutet, dass mein derzeitiges Verständnis von HttpContext.Current.Items falsch ist und dass dies keine geeignete Lösung für meine Bedürfnisse ist.

Meine Frage ist daher kann dies gemacht werden, um Threads in der gleichen Anfrage zu arbeiten und wenn ja sollte es, sonst welche geeignete Alternative gibt es?

+0

HttpContext.Current ist per-Thread wie Sie bereits selbst herausgefunden haben. Wenn Sie HttpContext.Current der aktuellen Anforderung in einem anderen Thread verwenden möchten, rufen Sie zuerst im aktuellen Thread einen Verweis darauf ab und übergeben Sie ihn dann an diesen anderen Thread. – Evk

+0

HttpContext.Current.Session ist ein Bereich, der einem einzelnen Benutzer gewidmet ist. Jedes in der Sitzung gespeicherte Objekt ist nur für den Benutzer/die Sitzung verfügbar, der es erstellt hat. – Eldho

+0

Ich verstehe, dass die Verwendung von Sitzungsspeicher keine gute Idee ist, weil der Arbeitsspeicher belegt ist (dies ist eines von vielen Dingen, die gespeichert werden können), aber auch nicht skalierbar, wenn die Site später in eine Load-Balanced-Umgebung wechselt? – ProNotion

Antwort

0

Eine Möglichkeit besteht darin, Session zum Speichern Ihrer Daten zu verwenden. Leider gilt dies nicht für API-spezifische Anfragen (z. B. mobiles Gerät ruft die Server-API auf). Außerdem erfordert der Server-Sitzungszustand, dass alle Daten serialisierbar sind (DB-Sitzungsstatus nicht).

Wenn die Sitzung Ihren Anforderungen nicht entspricht, sollten Sie mit der nächsten Option fortfahren: Verwenden des Caches, der durch etwas geschützt ist, das Ihre Anfragen von demselben Benutzer repräsentiert (a.k.a Zugriffs-Token).