Я читал здесь статью https://azure.microsoft.com/en-in/documentation/articles/service-fabric-work-with-reliable-collections/ В ней говорится: «Вы НЕ ДОЛЖНЫ изменять объект, как только вы передадите его в надежную коллекцию».Сервисная ткань надежные коллекции и неизменность
Почему это так? Могу ли я изменить объект и добавить его обратно в надежную коллекцию? Не перезапишет ли предыдущее значение?
Полное утверждение:
Однако надежные коллекции, этот код имеет ту же проблему, как уже обсуждалось, вы не должны изменить объект, как только вы дали его надежной коллекции.
Это утверждение относится к проблемам, связанным с работой над надежными коллекциями. При работе с надежными словарями SF API API будет выглядеть как стандартные .NET-словари. За кулисами это больше похоже на управление состоянием. При такой дифференциации нам нужно помнить об общих ошибках при работе с этими структурами данных. В первой демонстрации кода он будет выглядеть так, как будто он обновит объект, но не будет. Позже в статье он предоставил вам правильный способ изменения объекта в надежной коллекции.
Теоретически вы можете изменить один и тот же объект и написать его в надежной коллекции. Но этот подход является ошибочным. Когда вы вносите изменения в объект, значение изменяется только локально и не записывается на диск первичной и вторичной реплик. Пока вы явно не напишите модифицированный объект обратно в надежную коллекцию, локальная копия объекта и сохраненная копия не будут одинаковыми. Таким образом, всегда хорошая практика - рассматривать объект как неизменный и вносить изменения в глубокую копию объекта.
В традиционных коллекциях .net значение из ключевого поиска в словаре (или поп/просмотр из очереди) возвращает указатель на объект в куче. Когда вы изменяете этот указатель, значение в куче изменяется. В результате состояние мутируется в словаре.
Надежные коллекции - это фасад вокруг гораздо более сложного взаимодействия. Хотя верно, что коллекция находится в памяти *, надёжный менеджер штата также отвечает за репликацию любых изменений во вторичных репликах. Механизм, с помощью которого это происходит, вызывает CommitAsync в ITransaction.
Если вам нужно было только изменить представление объекта в памяти, изменение никогда не будет реплицировано на вторичные разделы, и это приведет к неопределенному/непредвиденному поведению. (скажем, когда активный первичный переключается на вторичный). Если вы вызываете CommitAsync (даже если вы выполняете Get -> Modify -> Set), транзакция может не выполнить фиксацию, а текущее в представлении памяти будет отличаться от текущего в памяти разделов и представления на диске основного раздела. Это снова приведет к неопределенному/неожиданному поведению.
* В большинстве случаев, если размер коллекции больше, чем доступная память. В этом случае значения выгружаются с диска, и в памяти хранятся только ключи и недавно используемые значения. В будущем, я слышал, что разговоры вокруг пейджинга продолжаются в хранилище памяти, когда давление диска увеличивается.