Gestione dei contrassegni per la rimozione definitiva

Articolo
10/17/2009

I contrassegni per la rimozione definitiva rappresentano elementi eliminati da una replica. Principalmente, i contrassegni per la rimozione definitiva consentono di impedire la reintroduzione di elementi eliminati in una replica. Per evitare potenziali problemi relativi alle prestazioni o all'archiviazione, i contrassegni per la rimozione definitiva devono essere periodicamente sottoposti a pulizia. Questa operazione deve essere gestita con attenzione per evitare la reintroduzione di elementi eliminati.

Rappresentazione di contrassegni per la rimozione definitiva

Una replica può utilizzare qualsiasi metodo per tenere traccia degli elementi eliminati. Per eseguire questa attività, si consiglia l'utilizzo di un bit o di un log di rimozione definitiva.

Bit di rimozione definitiva

Una replica stabilisce che i metadati per un elemento contengono un valore booleano che indica se l'elemento è stato eliminato dall'archivio di elementi. Quando un elemento viene eliminato, questo valore viene impostato su true nella voce di metadati per tale elemento. L'utilizzo di un bit di rimozione definitiva risulta efficace per l'archiviazione se è necessario tenere traccia di molti elementi eliminati, poiché richiede solo un bit aggiuntivo per elemento. Questo metodo è meno efficace per l'enumerazione o la pulizia dei contrassegni di rimozione definitiva poiché le ricerche devono essere eseguite nell'intero archivio di metadati.

Registro di rimozione definitiva

Una replica gestisce un log separato in cui sono elencati gli elementi eliminati dall'archivio di elementi. Quando un elemento viene eliminato, viene aggiunta una voce al log di rimozione definitiva. L'utilizzo di un log di rimozione definitiva non è efficace per l'archiviazione se è necessario tenere traccia di molti elementi eliminati poiché il log deve contenere un ID per ogni elemento eliminato. Questo metodo è efficace per l'enumerazione o la pulizia di contrassegni per la rimozione definitiva poiché l'elenco contiene solo elementi eliminati.

Pulizia dei contrassegni per la rimozione definitiva

Ogni replica in una community di sincronizzazione contiene solo la conoscenza sul proprio stato e non sullo stato di altre repliche. Di conseguenza, è impossibile determinare quando un contrassegno per la rimozione definitiva è stato replicato in tutta la community. Per questo motivo, per qualsiasi replica, stabilire il momento e la modalità per la pulizia dei contrassegni per la rimozione definitiva è una decisione completamente locale. Ad esempio, la pulizia dei contrassegni per la rimozione definitiva può avvenire in base al timestamp locale o ai requisiti di spazio. Una replica può disporre di criteri in base ai quali i contrassegni per la rimozione definitiva non possono occupare più del 10% del set di dati.

Dopo la pulizia di un contrassegno per la rimozione definitiva, una replica non è a conoscenza dell'eliminazione, ma deve comunque impedire la reintroduzione dell'elemento nell'archivio o in un'altra replica. Per evitare questo problema, la versione di creazione per ogni elemento e la conoscenza dimenticata della replica vengono conservate nell'archivio dei metadati per la replica. Quando un contrassegno per la rimozione definitiva viene pulito da una replica, nella conoscenza dimenticata deve essere registrata la versione di tale contrassegno.

Registrazione dei contrassegni per la rimozione definitiva puliti tramite codice gestito

Per registrare la rimozione dei metadati per un elemento eliminato dall'archivio dei metadati di una replica, chiamare ForgetTo sull'oggetto ForgottenKnowledge della replica. Questo metodo richiede la versione dell'elemento eliminato.

Registrazione dei contrassegni per la rimozione definitiva puliti tramite codice non gestito

Per registrare la rimozione dei metadati per un elemento eliminato dall'archivio dei metadati di una replica, chiamare IForgottenKnowledge::ForgetToVersion sull'oggetto IForgottenKnowledge della replica. Questo metodo richiede la versione dell'elemento eliminato.

Invio della conoscenza dimenticata a Sync Framework

Se una replica tiene traccia dei contrassegni per la rimozione definitiva puliti tramite la conoscenza dimenticata, il provider associato deve fornire la conoscenza dimenticata ai metodi Sync Framework che la richiedono, ad esempio ChangeBatch (per il codice gestito) o IProviderSyncServices::CreateChangeBatch (per il codice non gestito). La conoscenza dimenticata deve inoltre essere salvata con la conoscenza aggiornata durante la sincronizzazione, come nel metodo StoreKnowledgeForScope (per il codice gestito) o ISynchronousNotifyingChangeApplierTarget::SaveKnowledge (per il codice non gestito).

Se una replica non esegue la pulizia dei contrassegni per la rimozione definitiva e non conserva la conoscenza dimenticata, il provider associato deve passare null (per il codice gestito) o NULL (per il codice non gestito) ai metodi Sync Framework che includono un parametro della conoscenza dimenticata.

Scenari correlati ai contrassegni per la rimozione definitiva

Due scenari correlati ai contrassegni per la rimozione definitiva da considerare sono una replica non aggiornata che richiede la sincronizzazione e una replica che invia un aggiornamento a un elemento eliminato. Sync Framework rileva entrambi questi scenari.

Rilevamento di una replica non aggiornata

In questo scenario la replica di destinazione non è aggiornata rispetto alla replica di origine. Poiché nella replica di origine è stata eseguita la pulizia dei contrassegni per la rimozione definitiva, sono presenti eliminazioni di cui la replica di origine non è a conoscenza. Di conseguenza, il provider di origine non può inviare le modifiche che rappresentano tali eliminazioni al provider di destinazione. Prima che vengano applicate le modifiche, Sync Framework confronta la conoscenza dimenticata della replica di origine con la conoscenza corrente della replica di destinazione. Se la conoscenza della destinazione non contiene la conoscenza dimenticata, Sync Framework identifica la replica di destinazione come non aggiornata e avvia una sincronizzazione del recupero.

Se un'applicazione ha registrato un gestore eventi, Sync Framework offre all'applicazione la possibilità di proseguire o di arrestare l'enumerazione completa. Nel codice gestito, viene generato l'evento FullEnumerationNeeded. Nel codice non gestito, l'applicazione riceve un callback ISyncCallback::OnFullEnumerationNeeded.

Se l'applicazione non ha registrato un gestore eventi, verrà automaticamente eseguita l'enumerazione completa. Un'enumerazione completa consente a Sync Framework di confrontare le modifiche del provider di origine con gli elementi nella replica di destinazione e quindi di determinare gli elementi da eliminare dalla replica di destinazione. Qualsiasi elemento nella replica di destinazione a cui non corrisponde una modifica rispetto al provider di origine verrà eliminato dalla replica di destinazione.

Rilevamento di un aggiornamento a un elemento eliminato

In questo scenario la replica di origine non è aggiornata rispetto alla replica di destinazione. Ciò si verifica quando la replica di origine non è stata sincronizzata dall'ultima pulizia dei contrassegni per la rimozione definitiva da parte della replica di destinazione. Può verificarsi un problema quando per un elemento eliminato nella replica di destinazione è stato pulito il relativo contrassegno per la rimozione definitiva dalla replica di destinazione e questo stesso elemento è stato aggiornato nella replica di origine. L'elemento viene visualizzato nel batch di modifiche inviato dal provider di origine al provider di destinazione. È necessario che il provider di destinazione riconosca che l'elemento non è nuovo. In caso contrario, l'elemento sarà reintrodotto erroneamente nella replica di destinazione.

È importante considerare che la versione corrente di un elemento della replica di origine non è utile per eseguire il confronto con la conoscenza corrente della replica di destinazione, poiché la versione corrente dell'elemento che verrà reintrodotto non è contenuta nella conoscenza corrente della replica di destinazione. Al contrario, la versione di creazione dell'elemento della replica di origine viene confrontata con la conoscenza corrente della replica di destinazione per determinare se l'elemento era precedentemente noto alla replica di destinazione. Poiché l'eliminazione dell'elemento deve avvenire dopo la creazione dell'elemento e la conoscenza corrente della replica di destinazione contiene l'eliminazione, anche la conoscenza corrente deve contenere la creazione.

Di conseguenza, prima che il nuovo elemento venga aggiunto alla replica di destinazione, Sync Framework confronta la versione di creazione dell'elemento con la conoscenza corrente della replica di destinazione. Se la conoscenza della destinazione contiene la versione di creazione dell'elemento, l'elemento era precedentemente noto, ma è stato eliminato e dimenticato. L'elemento viene considerato come un conflitto aggiornamento-eliminazione.

Condividi tramite