Was Sie vermuten ist richtig, in einer Umgebung mit einem einzigen Ziel/Thread gibt es kaum einen Unterschied. Wenn Sie sich jedoch die Cache-Provider ansehen, ist auch in einem Multi-Thread-Szenario einiges los.
Die Art und Weise, wie ein Objekt aus seinem geänderten Zustand wieder in den Zwischenspeicher aufgenommen wird, ist in der nicht-strikten Version anders. Wenn Ihr Objekt zum Beispiel viel schwerer zu laden ist, Sie es aber nach einer Aktualisierung neu laden möchten, anstatt den nächsten Benutzer mit der Rechnung zu belasten, dann werden Sie bei strict und non-strict unterschiedliche Leistungen sehen. Ein Beispiel: Beim nicht-strikten Modell wird ein Objekt nach einer Aktualisierung einfach aus dem Cache geholt... der Preis für das Holen wird beim nächsten Zugriff anstelle eines Post-Update-Event-Handlers gezahlt. Beim strikten Modell wird die erneute Zwischenspeicherung automatisch durchgeführt. Ähnlich verhält es sich mit Einfügungen, bei denen das strict-Modell nichts unternimmt und das neu eingefügte Objekt in den Cache lädt.
Bei Non-Strict besteht außerdem die Möglichkeit eines Dirty Read, da der Cache zum Zeitpunkt des Lesens nicht gesperrt ist und Sie das Ergebnis der Änderung des Elements durch einen anderen Thread nicht sehen würden. Bei der strikten Variante wird der Cache-Schlüssel für dieses Element gesperrt und Sie werden aufgehalten, sehen aber das absolut letzte Ergebnis.
Wenn also selbst in einer Umgebung mit nur einem Ziel eine große Anzahl gleichzeitiger Lese-/Bearbeitungsvorgänge an Objekten stattfindet, besteht die Möglichkeit, dass die Daten nicht ganz korrekt sind.
Dies wird natürlich zu einem Problem, wenn eine Speicherung durchgeführt wird und ein Bearbeitungsbildschirm geladen wird: Die Person, die glaubt, die neueste Version des Objekts zu bearbeiten, ist es in Wirklichkeit nicht, und sie erlebt eine böse Überraschung, wenn sie versucht, die Änderungen an den veralteten Daten zu speichern, die sie geladen hat.
