Управление отметками полного удаления
Отметки полного удаления представляют элементы, удаленные из реплики. Главной задачей отметок полного удаления является защита от повторного добавления удаленных элементов в реплику. Чтобы избежать возможных проблем с производительностью или с хранением данных, необходимо периодически очищать отметки полного удаления. Такую очистку необходимо проводить осторожно, чтобы избежать повторного добавления удаленных элементов.
Представление отметок полного удаления
Реплика может использовать любой способ для отслеживания удаленных элементов. Рекомендуется использовать бит отметок полного удаления или журнал захоронения.
Бит полного удаления
Реплика определяет, что метаданные для элемента содержат логическое значение, указывающее, был ли элемент удален из хранилища элементов. Если элемент удален, в записи метаданных для этого элемента этот бит устанавливается в значение true. Использование бита полного удаления эффективно в хранилище, где нужно отслеживать большое количество удаленных элементов, поскольку для этого требуется только один дополнительный бит на элемент. Это способ менее эффективен для перечисления или очистки отметок полного удаления, поскольку необходимо выполнять поиск во всем хранилище метаданных.
Журнал захоронения
Реплика ведет отдельный журнал, в котором перечисляются элементы, удаленные из хранилища элементов. Когда элемент удаляется, в журнал отметок полного удаления добавляется запись. Использование журнала захоронения неэффективно в хранилищах, где нужно отслеживать большое количество удаленных элементов, поскольку журнал должен содержать идентификатор для каждого удаленного элемента. Этот способ эффективен для перечисления или очистки отметок полного удаления, поскольку в список входят только удаленные элементы.
Очистка отметок полного удаления
Каждая реплика в сообществе синхронизации содержит набор знаний только о собственном состоянии, но не о состоянии других реплик. Поэтому невозможно определить, прошла ли отметка полного удаления репликацию по всему сообществу. В результате для каждой отдельной реплики решение о времени и способе очистки отметок полного удаления применяется исключительно на основании локальных условий. Например, отметки полного удаления можно очищать на основании локальной отметки времени или исходя из требований к месту на диске. В реплике может действовать политика, запрещающая отметкам полного удаления занимать более 10 процентов набора данных.
После очистки отметки полного удаления реплика не получает сведений об удалении, однако по-прежнему должна предотвращать повторное добавление элемента в собственном хранилище или в другой реплике. Чтобы решить эту проблему, в хранилище метаданных для реплики хранится версия создания для каждого элемента и утраченный набор знаний для реплики. При очищении отметки полного удаления реплика должна сохранить версию этой отметки в своем наборе утраченных знаний.
Сохранение очищенных отметок полного удаления с помощью управляемого кода
Чтобы зарегистрировать тот факт, что метаданные удаленного элемента удалены из хранилища метаданных реплики, вызывается метод ForgetTo объекта ForgottenKnowledge данной реплики. Этому методу необходимо передать версию удаленного элемента.
Сохранение очищенных отметок полного удаления с помощью неуправляемого кода
Чтобы зарегистрировать тот факт, что метаданные удаленного элемента удалены из хранилища метаданных реплики, вызывается метод IForgottenKnowledge::ForgetToVersion объекта, реализующего интерфейс IForgottenKnowledge данной реплики. Этому методу необходимо передать версию удаленного элемента.
Обеспечение утраченных знаний службам Sync Framework
Если реплика отслеживает удаленные отметки полного удаления с помощью наборов утраченных знаний, связанный с этой репликой поставщик должен предоставить наборы утраченных знаний методам платформ Sync Framework, которые используют эти знания, например ChangeBatch (для управляемого кода) или IProviderSyncServices::CreateChangeBatch (для неуправляемого кода). Поставщик должен также сохранить утраченные наборы знаний вместе с обновленными наборами знаний, как это реализовано в методе StoreKnowledgeForScope (для управляемого кода) или ISynchronousNotifyingChangeApplierTarget::SaveKnowledge (для неуправляемого кода).
Если реплика не очищает отметки полного удаления и не хранит утраченные наборы знаний, связанный с этой репликой поставщик должен передать значение null (для управляемого кода) или NULL (для неуправляемого кода) тем методам платформ Sync Framework, которые принимают утраченные знания в качестве параметра.
Сценарии, связанные с отметками полного удаления
Следует рассмотреть две ситуации, связанные с отметками полного удаления: в одном случае устаревшая реплика запрашивает синхронизацию, а в другом реплика отправляет обновление для удаленного элемента. Платформа Sync Framework обнаруживает ситуации обоих типов.
Обнаружение устаревшей реплики
В этом сценарии реплика назначения является устаревшей по отношению к реплике источника. Поскольку в реплике источника очищены отметки полного удаления, существуют операции удаления, о которых неизвестно реплике источника. Поэтому поставщик источника не может отправить поставщику назначения изменения, которые представляют эти операции удаления. Перед применением изменений платформа Sync Framework сравнивает утраченный набор знаний реплики источника с текущим набором знаний реплики назначения. Если набор знаний назначения не содержит утраченный набор знаний, службы Sync Framework считают реплику назначения устаревшей и начинают синхронизацию восстановления.
Если приложение зарегистрировало обработчик события, платформа Sync Framework предоставит приложению возможность продолжить или остановить полное перечисление. В управляемом коде будет вызвано событие FullEnumerationNeeded. В неуправляемом коде приложение получит ответный вызов ISyncCallback::OnFullEnumerationNeeded.
Если приложение не зарегистрировало обработчик события, автоматически будет выполняться полное перечисление. Полное перечисление позволяет платформам Sync Framework сравнить изменения в поставщике источника с элементами в реплике назначения и таким образом определить, какие элементы должны быть удалены из реплики-назначения. Элементы реплики назначения, не содержащие соответствующих изменений в поставщике источника, будут удалены из реплики назначения.
Обнаружение обновления для удаленного элемента
В этом сценарии реплика источника является устаревшей по отношению к реплике назначения. Так бывает, когда реплика источника не была синхронизирована с момента последней очистки отметок полного удаления в реплике назначения. Может возникнуть проблема, если элемент был удален из реплики назначения, потом его отметка была очищена из реплики назначения, а затем тот же элемент был изменен в реплике источника. Элемент включается в пакет изменений, который поставщик источника отправляет поставщику назначения. Поставщик назначения должен иметь возможность определить, что этот элемент не является новым. В противном случае этот элемент будет повторно добавлен в реплику назначения.
Учтите, что нет смысла сравнивать текущую версию элемента из реплики источника с текущим набором знаний реплики назначения, поскольку текущая версия добавляемого элемента не содержится в текущем наборе знаний реплики назначения. Вместо этого версия создания элемента из реплики источника сравнивается с текущим набором знаний реплики назначения, чтобы определить, входил ли ранее элемент в набор знаний реплики назначения. Поскольку удаление элемента должно было случиться после создания элемента и в текущем наборе знаний реплики назначения содержится удаление, текущий набор знаний также должен содержать сведения о создании.
Поэтому перед добавлением нового элемента в реплику назначения платформа Sync Framework сравнивает версию создания элемента с текущим набором знаний реплики назначения. Если в набор знаний назначения входит версия создания элемента, это значит, что элемент ранее входил в набор знаний, но затем был удален и утрачен. Такой элемент считается конфликтом операций обновления и удаления.
См. также
Справочник
ISyncCallback::OnFullEnumerationNeeded
FullEnumerationNeeded