Strict vs NonStrict NHibernate Cache-Concurrency-Strategien

Question

Diese Frage bezieht sich auf den Unterschied zwischen Cache-Concurrency-Strategien ReadWrite und NonStrictReadWrite für den Cache der zweiten Ebene von NHibernate.

Wie ich es verstehe, ist der Unterschied zwischen diesen beiden Strategien ist relevant, wenn Sie eine verteilte repliziert haben Cache - nicht strikte wird nicht garantieren, dass ein Cache mit der exakt gleichen Wert wie ein anderer Cache hat, während strenge Lese-/Schreib sollte - Angenommen, der Cache-Provider führt die entsprechende verteilte Sperrung durch.

Der Teil, den ich nicht verstehe, ist, wie die Unterscheidung strict vs nonstrict relevant ist, wenn Sie einen einzelnen Cache oder einen verteilten partitionierten Cache (nicht repliziert) haben. Kann es relevant sein? Es scheint mir, dass in nicht replizierten Szenarien der Zeitstempel-Cache dafür sorgt, dass veraltete Ergebnisse nicht geliefert werden. Wenn es relevant sein kann, würde ich gerne ein Beispiel sehen.

Answer 1

Was Sie annehmen, ist richtig, in einer einzelnen Ziel-/Thread-Umgebung gibt es keinen großen Unterschied. Wenn Sie sich jedoch die Cache-Anbieter ansehen, wird selbst in einem Multi-Threaded-Szenario ein wenig weitergemacht.

Wie ein Objekt von seinem geänderten Zustand neu zwischengespeichert wird, ist im Nicht-Strikt anders. Zum Beispiel, wenn Ihr Objekt ist viel schwerer zu laden, aber Sie möchten es nach einem Update, anstatt den nächsten Benutzer mit der Rechnung zu Fuß, dann sehen Sie unterschiedliche Leistung mit strengen vs nicht-strikte. Beispiel: non-strict legt einfach ein Objekt aus dem Cache ab, nachdem eine Aktualisierung durchgeführt wurde ... Der Preis wird für den Abruf beim nächsten Zugriff anstatt für einen Ereignishandler nach der Aktualisierung bezahlt. Im strikten Modell wird der Re-Cache automatisch erledigt. Eine ähnliche Sache passiert mit Einfügungen, nicht-strikt wird nichts tun, wo strikt wird zurück und laden Sie das neu eingefügte Objekt in den Cache.

In nicht-strikte haben Sie auch die Möglichkeit einer schmutzigen lesen, da der Cache zum Zeitpunkt des Lesens nicht gesperrt war, würden Sie nicht das Ergebnis der Änderung eines anderen Threads auf das Element sehen. Genau genommen würde der Cacheschlüssel für diesen Gegenstand sperren und Sie würden aufgehalten, sehen aber das absolut letzte Ergebnis.

Also, selbst in einer einzigen Zielumgebung, wenn es eine große Menge gleichzeitiger Lese-/Bearbeitungsvorgänge an Objekten gibt, haben Sie die Möglichkeit, Daten zu sehen, die nicht wirklich genau sind.

Dies wird natürlich ein Problem, wenn ein Speichern durchgeführt wird und ein Bearbeitungsbildschirm geladen wird: Die Person, die denkt, dass sie die neueste Version des Objekts bearbeiten, ist es wirklich nicht und sie werden eine böse Überraschung erleben Sie versuchen, die Änderungen an den veralteten Daten zu speichern, die sie geladen haben.

Answer 2

Ich habe einen Beitrag here erstellt, der die Unterschiede erklärt. Bitte werfen Sie einen Blick und fühlen Sie sich frei zu kommentieren.