Gerenciando marcas de exclusão

Artigo
10/17/2009

As marcas de exclusão representam itens que foram excluídos de uma réplica. As marcas de exclusão ajudam a proteger contra a reintrodução de itens excluídos em uma réplica. Para evitar possíveis problemas de desempenho e de armazenamento, as marcas de exclusão devem ser limpas periodicamente. Esta limpeza deve ser gerenciada cuidadosamente para evitar a reintrodução de itens excluídos.

Representando marcas de exclusão

Uma réplica pode usar qualquer método para rastrear itens excluídos. Para executar esta tarefa, é recomendável que uma réplica use um bit ou um log de marca de exclusão.

Bit de marca de exclusão

A réplica define que os metadados para um item contêm um valor Booleano que indica se um item foi excluído do repositório de itens. Quando um item é excluído, este valor é definido como verdadeiro na entrada de metadados do item. O bit de marca de exclusão é eficiente para o armazenamento se for necessário rastrear vários itens excluídos, pois só requer um bit adicional por item. Este método é menos eficiente para enumerar ou limpar marcas de exclusão, pois o repositório de itens deve ser pesquisado por completo.

Log de marca de exclusão

A réplica mantém um log separado que lista itens excluídos do repositório de itens. Quando um item é excluído, uma entrada é adicionada ao log da marca de exclusão. Um log de marca de exclusão é ineficiente para armazenamento se for necessário rastrear vários itens excluídos, pois o log deve conter uma ID para cada item que foi excluído. Este método é eficiente para enumerar e limpar marcas de exclusão, pois a lista contém somente itens excluídos.

Limpeza de marca de exclusão

Cada réplica em uma comunidade de sincronização só contém conhecimento sobre seu próprio estado e não do estado de outra réplica. Portanto, é impossível determinar quando uma marca de exclusão foi replicada pela comunidade. Então, para qualquer réplica específica, a determinação de quando e como limpar marcas de exclusão é uma decisão local. Por exemplo, as marcas de exclusão podem ser limpas com base no carimbo de data e hora ou nos requisitos de espaço. Uma réplica pode ter uma política para que marcas de exclusão não ocupem mais de 10% do conjunto de dados.

Depois que uma marca de exclusão é limpa, a réplica não fica sabendo da exclusão, mas ainda deve evitar que o item seja reintroduzido no seu próprio repositório ou em outro réplica. Para ajudar a evitar este problema, a versão de criação de cada item e o conhecimento esquecido da réplica são mantidos no repositório de metadados da réplica. Quando uma réplica limpa uma marca de exclusão, ela deve registrar a versão de marca de exclusão no em seu conhecimento esquecido.

Registrando marcas de exclusão limpas usando código gerenciado

Para registrar que metadados para um item excluído foram removidos do repositório de metadados de uma réplica, chame ForgetTo no objeto ForgottenKnowledge da réplica. Este método exige a versão do item excluído.

Registrando marcas de exclusão limpas usando código não gerenciado

Para registrar que metadados para um item excluído foram removidos do repositório de metadados de uma réplica, chame IForgottenKnowledge::ForgetToVersion no objeto IForgottenKnowledge da réplica. Este método exige a versão do item excluído.

Fornecendo conhecimento esquecido para Sync Framework

Se uma réplica rastreia marcas de exclusão limpas usando o conhecimento esquecido, o provedor associado deve fornecer o conhecimento esquecido para métodos do Sync Framework que exigem este, como ChangeBatch (para código gerenciado) ou IProviderSyncServices::CreateChangeBatch (para código não gerenciado). O provedor também deve salvar o conhecimento esquecido junto com o conhecimento atualizado durante a sincronização, como em seu método StoreKnowledgeForScope (para código gerenciado) ou no método ISynchronousNotifyingChangeApplierTarget::SaveKnowledge (para código não gerenciado).

Se uma réplica não limpar marcas de exclusão e não mantiver conhecimento esquecido, seu provedor associado deverá passar null (para código gerenciado) ou NULL (para código não gerenciado) para métodos Sync Framework que tenham um parâmetro de conhecimento esquecido.

Cenários relacionados a marca de exclusão

Dois cenários relativos a marcas de exclusão que devem ser considerados são de uma réplica desatualizada que está solicitando sincronização e de uma réplica que envia uma atualização para um item excluído. O Sync Framework detecta ambos cenários.

Detectando uma réplica desatualizada

Neste cenário, a réplica de destino está desatualizada em relação à réplica de origem. Uma vez que a réplica de origem limpou suas marcas de exclusão, há exclusões que a réplica de origem não tem conhecimento. Portanto, o provedor de origem não pode enviar alterações que representam essas exclusões para o provedor de destino. Antes das alterações serem aplicadas, o Sync Framework compara o conhecimento esquecido da réplica de origem com o conhecimento atual da réplica de destino. Se o conhecimento de destino não contiver o conhecimento esquecido, o Sync Framework identificará a réplica de destino como desatualizada e começará uma sincronização de recuperação.

Se um aplicativo registrou um manipulador de eventos, o Sync Framework dará ao aplicativo a oportunidade de continuar ou parar a enumeração completa. No código gerenciado, o evento FullEnumerationNeeded será acionado. No código não gerenciado, o aplicativo receberá um retorno de chamada ISyncCallback::OnFullEnumerationNeeded.

Se o aplicativo não registrou um manipulador de eventos, a enumeração completa ocorrerá automaticamente. Uma enumeração completa permite que o Sync Framework compare alterações do provedor de origem com itens na réplica de destino e, dessa forma, determine quais itens devem ser excluídos da réplica de destino. Qualquer item na réplica de destino que não tem uma alteração correspondente do provedor de origem será excluído da réplica de destino.

Detectando uma atualização de um item excluído

Neste cenário, a réplica de origem está desatualizada em relação à réplica de destino. Isso ocorre quando a réplica de origem não foi sincronizada desde a última vez que a réplica de destino limpou suas marcas de exclusão. Um problema pode ocorrer quando um item excluído da réplica de destino teve sua marca de exclusão subsequentemente limpa da réplica de destino e aquele mesmo item foi atualizado na réplica de origem. O item aparece no lote de alterações que o provedor de origem envia ao provedor de destino. O provedor de destino deve reconhecer que este item não é um item novo; caso contrário, o item será reintroduzido incorretamente na réplica de destino.

Lembre-se que a versão atual de um item da réplica de origem não serve para comparar com o conhecimento atual da réplica de destino, pois a versão atual do item que seria reintroduzido não está contida no conhecimento atual da réplica de destino. Em vez disso, a versão de criação do item da réplica de origem é comparada ao conhecimento atual da réplica de destino para determinar se o item era previamente conhecido pela réplica de destino. Como a exclusão do item deve ter ocorrido depois da criação do item e o conhecimento atual da réplica de destino contém a exclusão, o conhecimento atual deve conter a criação.

Portanto, antes que um novo item seja adicionado a uma réplica de destino, o Sync Framework compara a versão de criação do item com o conhecimento atual da réplica de destino. Se o conhecimento de destino contém a versão de criação do item, este foi previamente conhecido, mas foi excluído e esquecido. O item é tratado como um conflito de atualização-exclusão.

Compartilhar via