Share via


Controlar los conflictos

Para asegurar que los cambios realizados en los elementos de la comunidad de sincronización se propagan correctamente, el proveedor de destino debe detectar y controlar los conflictos que se producen entre los elementos enviados desde el proveedor de origen y los elementos de la réplica de destino. Sync Framework proporciona objetos aplicadores de cambios que realizan la mayor parte del trabajo necesario para detectar y controlar conflictos.

Sync Framework admite dos categorías de conflictos que se pueden producir durante la sincronización: conflictos de simultaneidad y conflictos de restricción. Los conflictos de simultaneidad se producen cuando se cambia el mismo elemento o la misma unidad de cambio en dos réplicas distintas que se sincronizan posteriormente. Los conflictos de restricción son los que infringen las restricciones aplicadas a los elementos o unidades de cambio, como la relación de las carpetas o la ubicación de los datos con un nombre idéntico dentro de un sistema de archivos.

Sync Framework proporciona dos mecanismos para que una aplicación de sincronización especifique cómo se administran los conflictos: establecer una directiva de resolución de conflictos que se aplique a todos los conflictos que se producen durante una sesión o registrarse para recibir una notificación de cada conflicto cuando se detecte, de modo que los conflictos puedan examinarse y resolverse de forma individual.

Flujo de ejecución del control de conflictos

Los conflictos se detectan y controlan durante la fase de aplicación de cambios de la sincronización. Normalmente, esto se produce en el método ProcessChangeBatch (en código administrado) o en el método ProcessChangeBatch (en código no administrado) del proveedor de destino.

Cuando el proveedor de destino utiliza un aplicador de cambios de Sync Framework, se siguen los pasos que se describen a continuación en cada elemento del lote de cambios.

  1. El aplicador de cambios comprueba si alguna actualización para el elemento de la réplica de destino hace que el elemento tenga un conflicto de simultaneidad con el cambio del origen. Por ejemplo, cuando el elemento se ha modificado localmente en la réplica de origen y de destino, se detecta un conflicto de actualización-actualización.

  2. Si la aplicación ha especificado una directiva de resolución de conflictos para los conflictos de simultaneidad, el aplicador de cambios asigna una acción de resolución de conflictos en función de esta directiva. De lo contrario, el aplicador de cambios notifica a la aplicación el conflicto y la aplicación especifica la acción resolución de conflictos.

  3. El aplicador de cambios envía una llamada al proveedor de destino para aplicar el cambio en función de la acción de resolución de conflictos. Por ejemplo, eliminar el elemento de la réplica de destino y reemplazarlo por el elemento del proveedor de origen.

  4. Cuando el proveedor de destino aplica el cambio en la réplica de destino, el proveedor de destino detecta conflictos de restricción. Por ejemplo, el cambio del origen se identifica mediante id1 y se denomina "FavoriteBooks", pero la réplica de destino contiene un elemento que se identifica mediante id2 que también se denomina "FavoriteBooks." La réplica de destino los reconoce como el mismo elemento porque tienen el mismo nombre, pero Sync Framework los reconoce como elementos diferentes porque tienen identificadores distintos. El proveedor de destino notifica un conflicto de restricción al aplicador de cambios.

  5. Cuando la aplicación ha especificado una directiva de resolución de conflictos de colisión y el conflicto de restricción se debe a una colisión, el aplicador de cambios asigna una acción de resolución de conflictos con arreglo a esta directiva. De lo contrario, el aplicador de cambios notifica a la aplicación el conflicto y la aplicación especifica la acción resolución de conflictos.

  6. El aplicador de cambios envía una llamada al proveedor de destino para aplicar el cambio en función de la acción de resolución de conflictos.

Para obtener más información sobre el control de conflictos de simultaneidad, vea Detectar y resolver conflictos de simultaneidad.

Para obtener más información sobre el control de conflictos de restricción, vea Detectar y resolver conflictos de restricción.

Reducir los conflictos utilizando unidades de cambio

El número de conflictos se puede reducir utilizando unidades de cambio para representar los cambios del subelemento. Cuando se utilizan unidades de cambio, se realiza el seguimiento de las versiones en conjunto para las unidades de cambio en lugar de para el elemento. Por consiguiente, los cambios que se realizan en unidades de cambio diferentes dentro del mismo elemento no producirán un conflicto. Para obtener más información, vea Sincronizar las unidades de cambio.

Guardar los conflictos en un registro

Puede resultar útil guardar los conflictos en un registro para que se puedan procesar de forma independiente respecto a la sesión de sincronización, como cuando el usuario va a comprobar los conflictos y a decidir cómo resolverlos. Además, cuando los conflictos de restricción se resuelven combinando los datos de los dos elementos en conflicto, el aplicador de cambios puede, en algunos casos, utilizar el registro de conflictos para almacenar temporalmente conflictos durante una sesión de sincronización.

Para obtener más información acerca de cómo crear y utilizar un registro de conflictos, vea Registrar y administrar conflictos.

Vea también

Referencia

Interfaz ISynchronousNotifyingChangeApplier
Interfaz ISynchronousNotifyingChangeApplierTarget
NotifyingChangeApplier
INotifyingChangeApplierTarget

Conceptos

Implementar un proveedor estándar personalizado
Aplicar los cambios