none
UploadAndDownload sync with DestinationWins RRS feed

  • Question

  • I have two stores, each contains the same item at beginning. Then I updated the two stores separately to create a conflict, and then tried to sync the stores. The policy said it was a UploadAndDownload sync and conflict-resolving rules for both local provider and remote provider were set to DestinationWins.

    I anticipated that both stores were unchanged because during upload the destination won so upload had no effects, and same for the download process. However after sync both stores were updated to the version in remote store:

    Initial state

    =======

    Store A: "Value 1"

    Store B: "Value 1"

    After edit

    =======

    Store A: "Value 2"

    Store B: "Value 3" 

    After sync (UploadAndDownload with DestinationWins)

    =======

    Store A: "Value 3"

    Store B: "Value 3"

    My question is how "Value 3" got propergated into Store A during the sync? During download Store A was the destination and destination should have won, right?

     

    Wednesday, March 31, 2010 12:02 AM

Answers

  • Not quite :-).  I'm assuming that Store B is your remote store.  This means that the conflict will get resolved on the destination during the Upload part, and that resolution will be propagated to Store A during the download part.  If we triggered another conflict, the sync framework wouldn't be particularly helpful.

    Here's your example, augmented with sync metadata, and breaking sync into two parts.  At the beginning I will assume that both stores are completely in sync:

    Initial state

    =======

    Store A: "Value 1", Update Version = A1, Store Knowledge: A1B1

    Store B: "Value 1", Update Version = A1, Store Knowledge: A1B1

    After edit

    =======

    Store A: "Value 2", Update Version = A2, Store Knowledge: A2B1

    Store B: "Value 3", Update Version = B2, Store Knowledge: A1B2

    At this point, your replicas are in conflict.  Note that this is because A's change is not contained in B's knowledge _AND_ B's change is not contained in A's knowledge.  If both cases aren't true, you don't have a conflict.

    After first part of sync (Upload to Store B with DestinationWins)

    =======

    Store A: "Value 2", Update Version = A2, Store Knowledge: A2B1

    Store B: "Value 3", Update Version = B3, Store Knowledge: A2B3

    There are two important things to notice about this.  The first is that the Update Version of the change on store B got a new version from before.  The second thing to notice is that store B's knowledge includes store A's knowledge, so it learned the knowledge about the item from store A.  What this means is that the conditions I meant above are no longer satisfied, and you have no conflict.  From the sync point of view, it's just an update on store B that needs to sync to A.

    After last sync part (Download to Store A with DestinationWins)

    =======

    Store A: "Value 3", Update Version = B3, Store Knowledge: A2B3

    Store B: "Value 3", Update Version = B3, Store Knowledge: A2B3

    I hope this clears things up.  If you want the behavior you describe, you can either switch the sync direction to be DownloadAndUpload, or do the same sync direction order and switch the remote/local providers on the orchestrator, or you could switch your local and remote providers on the sync orchestrator.  You could also use SourceWins.

    Hope this helps,

    Aaron


    SDE, Microsoft Sync Framework
    Wednesday, March 31, 2010 12:30 AM
    Answerer

All replies

  • My working theory is this:

    1. During upload the conflict was detected and automatically resolved, and item in store B was updated to a new revision number with value "Value 3".

    2. During download, since the item in store B had a higher revision number so it was not detected as a conflict but a normal update. Hence it was downloaded and replaced item in store A.

    Is this a correct understanding?

    Wednesday, March 31, 2010 12:21 AM
  • Not quite :-).  I'm assuming that Store B is your remote store.  This means that the conflict will get resolved on the destination during the Upload part, and that resolution will be propagated to Store A during the download part.  If we triggered another conflict, the sync framework wouldn't be particularly helpful.

    Here's your example, augmented with sync metadata, and breaking sync into two parts.  At the beginning I will assume that both stores are completely in sync:

    Initial state

    =======

    Store A: "Value 1", Update Version = A1, Store Knowledge: A1B1

    Store B: "Value 1", Update Version = A1, Store Knowledge: A1B1

    After edit

    =======

    Store A: "Value 2", Update Version = A2, Store Knowledge: A2B1

    Store B: "Value 3", Update Version = B2, Store Knowledge: A1B2

    At this point, your replicas are in conflict.  Note that this is because A's change is not contained in B's knowledge _AND_ B's change is not contained in A's knowledge.  If both cases aren't true, you don't have a conflict.

    After first part of sync (Upload to Store B with DestinationWins)

    =======

    Store A: "Value 2", Update Version = A2, Store Knowledge: A2B1

    Store B: "Value 3", Update Version = B3, Store Knowledge: A2B3

    There are two important things to notice about this.  The first is that the Update Version of the change on store B got a new version from before.  The second thing to notice is that store B's knowledge includes store A's knowledge, so it learned the knowledge about the item from store A.  What this means is that the conditions I meant above are no longer satisfied, and you have no conflict.  From the sync point of view, it's just an update on store B that needs to sync to A.

    After last sync part (Download to Store A with DestinationWins)

    =======

    Store A: "Value 3", Update Version = B3, Store Knowledge: A2B3

    Store B: "Value 3", Update Version = B3, Store Knowledge: A2B3

    I hope this clears things up.  If you want the behavior you describe, you can either switch the sync direction to be DownloadAndUpload, or do the same sync direction order and switch the remote/local providers on the orchestrator, or you could switch your local and remote providers on the sync orchestrator.  You could also use SourceWins.

    Hope this helps,

    Aaron


    SDE, Microsoft Sync Framework
    Wednesday, March 31, 2010 12:30 AM
    Answerer
  • Thank you Aaron! Excellent answer!
    Wednesday, March 31, 2010 6:42 PM
  • After last sync should the item in Store A have updated version A3 instead of B3? And The knowledge should be A3B3?
    Wednesday, March 31, 2010 6:50 PM
  • After the last sync, since there was no conflict, you want it to be the update version from B.  That way, if you sync again, you don't send the change needlessly.  Similarly, the knowledge shouldn't be updated either (the knowledge would be updated by the change applier to contain the version, so without the update on A, the knowledge wouldn't get updated).

    Aaron


    SDE, Microsoft Sync Framework
    Monday, April 5, 2010 8:40 PM
    Answerer
  • Aaron, could you be so kind to explain me why in the first upload the version of the item in B store needs to be updated again to B3?

    I mean, if the version of the item in the in B store was B2 after the first upload wouldn't "Value 3" be synched the same on A store? (Since Store Knowledge of Store B would be A2B2 so still different from the Store Knowledge of store A that is A2B1)

    Thanks a lot

    Best regards 

    Thursday, November 24, 2011 7:27 PM