Mit 'HttpContext.Current.Cache' sicher

Question

ich Cache in einer Web-Service-Methode wie folgt bin mit:

var pblDataList = (List<blabla>)HttpContext.Current.Cache.Get("pblDataList"); 

if (pblDataList == null) 
{ 
    var PBLData = dc.ExecuteQuery<blabla>(@"SELECT blabla"); 

    pblDataList = PBLData.ToList(); 

    HttpContext.Current.Cache.Add("pblDataList", pblDataList, null, 
     DateTime.Now.Add(new TimeSpan(0, 0, 15)), 
     Cache.NoSlidingExpiration, CacheItemPriority.Normal, null); 
} 

Aber ich frage mich, ist dieser Code Thread-sicher? Die Web-Service-Methode wird von mehreren Anforderern aufgerufen. Und mehr als ein Anforderer kann versuchen, Daten abzurufen und zur Cache zur gleichen Zeit hinzuzufügen, während der Cache leer ist.

Die Abfrage dauert 5 bis 8 Sekunden. Würde die Einführung einer Lock-Anweisung um diesen Code mögliche Konflikte verhindern? (Ich weiß, dass mehrere Abfragen gleichzeitig ausgeführt werden können, aber ich möchte sicherstellen, dass immer nur eine Abfrage ausgeführt wird.)

Answer 1

Das Cache-Objekt ist thread-sicher , aber HttpContext.Current wird nicht von Hintergrundthreads verfügbar sein. Dies kann oder kann nicht auf Sie zutreffen, es ist nicht offensichtlich aus Ihrem Code-Snippet, ob Sie tatsächlich Hintergrund-Threads verwenden oder nicht, aber für den Fall, dass Sie jetzt oder zu einem späteren Zeitpunkt entscheiden, sollten Sie dies im Hinterkopf behalten .

Wenn es eine Chance gibt, dass Sie von einem Hintergrundthread auf den Cache zugreifen müssen, verwenden Sie stattdessen HttpRuntime.Cache.

Obwohl einzelne Operationen im Cache Thread-sicher sind, sind sequenzielle Lookup/Store-Operationen offensichtlich nicht atomar. Ob Sie brauchen, um atomar zu sein, hängt von Ihrer speziellen Anwendung ab. Wenn es ein schwerwiegendes Problem sein könnte, dass die gleiche Abfrage mehrmals ausgeführt wird, dh wenn sie mehr Last erzeugt, als Ihre Datenbank verarbeiten kann, oder wenn es ein Problem für eine Anforderung wäre, Daten zurückzugeben, die sofort in der Datenbank überschrieben werden Cache, dann würden Sie wahrscheinlich eine Sperre um den gesamten Codeblock platzieren möchten.

In den meisten Fällen möchten Sie jedoch wirklich zuerst Profil und sehen, ob das tatsächlich ein Problem ist. Die meisten Webanwendungen/Dienste befassen sich nicht mit diesem Aspekt des Caching, da sie zustandslos sind und es keine Rolle spielt, ob der Cache überschrieben wird.

Answer 2

Sie haben Recht. Die Abruf- und Addiervorgänge werden nicht als atomare Transaktion behandelt. Wenn Sie verhindern müssen, dass die Abfrage mehrmals ausgeführt wird, müssen Sie eine Sperre verwenden.

(Normalerweise wäre dies nicht ein Problem viel, aber im Fall einer Abfrage mit langer Laufzeit kann es nützlich sein, Belastung für die Datenbank zu entlasten.)

Answer 3

glaube ich, die Add Thread-sicher sein sollte - dh es wird kein Fehler, wenn Add wird zweimal mit dem gleichen Schlüssel aufgerufen, aber offensichtlich könnte die Abfrage zweimal ausführen.

Eine andere Frage ist jedoch ist die Daten Thread-Safe. Es gibt keine Garantie, dass jeder List<blabla> isoliert ist - es hängt vom Cache-Provider ab. Der speicherinterne Cache-Provider speichert die Objekte direkt. Es besteht daher die Gefahr von Kollisionen, wenn einer der Threads die Daten bearbeitet (Elemente in der Liste hinzufügen/entfernen/auslagern oder Eigenschaften eines Elements ändern). Aber mit einem Serialisierung Anbieter sollten Sie in Ordnung sein. Natürlich erfordert dies dann, dass blabla serialisierbar ist ...