Le Blog de Pi-R (Pierre Cambier)

Réplication SQL pour les projets mobiles : Gestion des conflits et résolveurs - PARTIE 1/2 (Généralités)

Introduction :

La réplication SQL de fusion permet de disposer de plusieurs bases répliquées sur les différents terminaux mobiles. Ces différentes bases SQL Server Compact sont toutes des répliquas d’une seule et même base centrale SQL Server. La réplication permet à toutes ces différentes bases (base serveur et bases mobiles) de mettre à jour leurs données de manière autonome.

Dans certaines typologies, la réplication peut donc permettre à plusieurs bases d’effectuer des changements sur la même ligne de données. Lorsque les terminaux concernés synchroniseront avec la base centrale, il y aura donc un ou plusieurs cas de conflits : quelles mises à jour vont être prises en compte ? Quelle ligne modifiée sera la “ligne gagnante” d’un conflit particulier ?

Détection de conflits et niveaux de suivi :

Qu'une modification de données provoque ou non un conflit dépend du type de suivi de conflit qui est défini pour chacun des articles (= tables).

Dans le cadre de la réplication de fusion pour SQL Server Compact, il existe deux types de suivi : le suivi au niveau de la ligne ou le suivi au niveau de la colonne. En fait, ce sont ces deux types de suivi qui permettent de déterminer comment les conflits sont détectés lors des phases de synchronisation.

En résumé, voici ce qu’il faut retenir :

• Si le suivi des conflits s’effectue au niveau des colonnes, il y a conflit si des modifications sont apportées à la même colonne d'une même ligne sur plusieurs nœuds de réplication.
• Si le suivi des conflits s’effectue au niveau des lignes, il y a conflit si des modifications sont apportées à des colonnes quelconques d'une même ligne sur plusieurs nœuds de réplication (les colonnes affectées dans les lignes correspondantes ne doivent pas forcément être identiques).

Remarques importantes :

• Le suivi au niveau de la colonne réduit le nombre de conflits quand les applications mobiles permettent à différents utilisateurs de modifier les mêmes données.
• Le suivi au niveau de la colonne est un bon moyen de réduire la quantité d'informations qui doivent être envoyées au serveur de publication au cours de la synchronisation, tandis que le suivi de niveau ligne nécessite moins de surcharge en matière de suivi, mais a besoin de plus de stockage pour effectuer le suivi des modifications.
• Peu importe le type de suivi, la résolution du conflit sera identique : toute la ligne de données sera écrasée par les données du vainqueur du conflit.

C’est la sémantique des applicatifs qui détermine l’option de suivi à appliquer sur chacun des articles d’une publication. Dans le cas où la mise à jour de plusieurs champs s’effectue en même temps (ex : le même écran pour modifier l’ensemble des coordonnées d’un client), il est préférable d’utiliser le suivi par ligne. Si les mises à jour des champs se font de manière individuelle, le suivi au niveau de la colonne est le mieux adapté, et permettra d’éviter de provoquer des détections de conflits inutiles.

Une option de suivi est attribuée à un article particulier. Les articles d’une même publication peuvent avoir des options de suivi différentes selon les besoins.

L’option de suivi, à utiliser pour un article particulier, peut être définie facilement dans les propriétés des articles. Après avoir sélectionné l’article à éditer, il est question de renseigner le champ “Tracking level” avec la valeur “Row-level tracking” (suivi de la ligne) ou “Column-level tracking” (suivi de la colonne) :

Résolution de conflits et résolveurs :

Un programme de résolution de conflits (ou “résolveur”) est associé à chacun des articles de la publication. Il peut s’agir du même programme, ou d’un programme différent selon les articles et les besoins.

Après la détection d’un conflit, le moteur de réplication lance le programme de résolution de conflits sélectionné sur l’article (ou celui par défaut) pour déterminer le “vainqueur du conflit”. La ligne gagnante est appliquée au serveur de publication et à l’abonné tandis que les données de la ligne perdante sont automatiquement stockées dans des tables systèmes.

Les conflits sont toujours résolus automatiquement par les différents résolveurs et immédiatement par l'agent de fusion.

Le résolveur par défaut :

Pour utiliser le résolveur de conflits pas défaut, il n’est pas nécessaire d’effectuer des manipulations particulières de paramétrage. En effet, le résolveur par défaut est automatiquement attribué à chacun des articles lors de leur création.

Le résolveur par défaut propose plusieurs méthodes de résolution des conflits qui sont généralement les mieux adaptées aux différentes applications :

• Si un conflit se produit entre la base serveur et un abonné, la modification du serveur est conservée tandis que celle de l'abonné est annulée.
• Si un conflit se produit entre deux abonnés, la modification provenant du premier abonné qui se synchronise avec le serveur est conservée tandis que celle provenant du second abonné est annulée.

Utiliser un autre résolveur :

SQL Server propose toute une liste de résolveurs prédéfinis qui ont chacun des propriétés différentes en ce qui concerne les résolutions de conflits.

Pour utiliser un autre résolveur sur un article particulier, il est d’abord nécessaire d’entrer dans l’édition des propriétés de cet article, et de sélectionner l’onglet “Resolver” :

Par défaut, le résolveur par défaut sera sélectionné (“Use the default resolver”). Sélectionnez donc la seconde option pour choisir un autre modèle de résolveur dans la liste (“Use a custom resolver”) :

Les méthodes proposées par chacun de ces autres résolveurs sont évidemment différentes et seront importantes pour déterminer la “ligne gagnante” de chaque conflit. Il est important d’effectuer un choix judicieux selon les besoins, car il en dépend de la conformité des données de la base.

Par exemple, en sélectionnant le résolveur “DATETIME (Earlier Wins)”, le résolveur considèrera que la ligne modifiée en premier (par rapport à un champ de type DateTime qui doit être précisé) sera systématiquement la gagnante d’un conflit.

Peu importe le résolveur utilisé, après résolution d’un conflit, l’agent de fusion journalise systématiquement les données du conflit en fonction du type de conflit dans des tables systèmes, et par article.

Les données de ces tables de réplication sont purgées au terme de la période de rétention.

Rédaction d’un résolveur personnalisé en C# :

A suivre…

Pi-R.