Ich habe hier einen Artikel gelesen https://azure.microsoft.com/en-in/documentation/articles/service-fabric-work-with-reliable-collections/ Es heißt "Sie dürfen ein Objekt nicht ändern, sobald Sie es einer zuverlässigen Sammlung gegeben haben."Service Stoff zuverlässige Sammlungen und Unveränderlichkeit
Warum ist das der Fall? Kann ich das Objekt nicht ändern und zur zuverlässigen Sammlung hinzufügen? Wird der vorherige Wert nicht überschrieben?
Die vollständige Erklärung ist:
jedoch mit zuverlässigen Sammlungen, dieser Code zeigt das gleiche Problem wie bereits angesprochen: Sie müssen ein Objekt nicht ändern, wenn Sie es auf eine zuverlässige Sammlung gegeben haben.
Diese Aussage steht im Zusammenhang mit Problemen, die mit der Arbeit an zuverlässigen Sammlungen verbunden sind. Wenn Sie mit SF-zuverlässigen Wörterbüchern arbeiten, wird die API wie Standard-.NET-Wörterbücher aussehen. Hinter den Kulissen macht es mehr wie die Verwaltung des Staates. Bei dieser Differenzierung müssen wir uns mit den üblichen Fallstricken bei der Arbeit mit diesen Datenstrukturen auseinandersetzen. In der ersten Codedemonstration wird es so aussehen, als würde es das Objekt aktualisieren, aber nicht. Später in dem Artikel gab es Ihnen die richtige Möglichkeit, ein Objekt in der zuverlässigen Sammlung zu ändern.
Theoretisch können Sie das gleiche Objekt ändern und es wieder in die zuverlässige Sammlung schreiben. Aber dieser Ansatz ist fehlerhaft. Wenn Sie Änderungen am Objekt vornehmen, wird der Wert nur lokal geändert und nicht auf den Datenträger der primären und sekundären Replikate geschrieben. Bis Sie das geänderte Objekt explizit in die zuverlässige Sammlung schreiben, sind die lokale Kopie des Objekts und die persistente Kopie nicht identisch. Es ist also immer eine gute Übung, das Objekt als unveränderlich zu behandeln und Modifikationen an der Tiefenkopie des Objekts vorzunehmen.
In traditionellen .net-Auflistungen gibt der Wert aus einer Schlüsselsuche in einem Wörterbuch (oder einem Pop/Peek aus einer Warteschlange) einen Zeiger auf ein Objekt im Heap zurück. Wenn Sie diesen Zeiger ändern, wird der Wert im Heap geändert. Infolgedessen ist der Zustand im Wörterbuch mutiert.
Zuverlässige Sammlungen sind eine Fassade um eine viel komplexere Interaktion. Obwohl es wahr ist, dass die Sammlung im Speicher * ist, ist der zuverlässige Zustandsverwalter auch dafür verantwortlich, alle Änderungen an den sekundären Replikaten zu replizieren. Der Mechanismus, durch den das auftritt, ruft CommitAsync für die ITransaction auf.
Wenn Sie nur die In-Memory-Repräsentation eines Objekts mutieren, wird die Änderung niemals auf sekundäre Partitionen repliziert und es kommt zu undefiniertem/unerwartetem Verhalten. (Wenn das aktive Primärsystem zu einem Sekundärsystem wechselt) Wenn Sie CommitAsync aufrufen (selbst wenn Sie Get -> Modify -> Set), kann die Transaktion möglicherweise nicht festgeschrieben werden, und die aktuelle Arbeitsspeicherdarstellung unterscheidet sich von der Sekundärseite Partitionen und die Darstellung auf der Festplatte der primären Partition. Dies führt wiederum zu undefiniertem/unerwartetem Verhalten.
* In den meisten Fällen, außer die Größe der Sammlung ist größer als der verfügbare Speicher. In diesem Fall werden die Werte von der Platte ausgelagert und nur die Schlüssel und die zuletzt verwendeten Werte werden im Speicher gehalten. In der Zukunft habe ich gehört, dass ich weiter blob speichere, wenn der Druck steigt.