RetryWithForceWrite on a ClientUpdateServerDelete conflict behavior RRS feed

  • Question

  • I just wanted to verify that the behavior for using RetryWithForceWrite in the case of a ClientUpdateServerDelete. I am using the example from the documentation under the heading "How to: Handle Data Conflicts and Errors".

    This example forces a series of conflicts. One of the conflicts force a ClientUpdateServerDelete error. Surrounding this error I see the following database actions when I trace the commands on the server:

    1. The defined usp_CustomerApplyUpdate  (the apply update script) is executed to apply the update
    2. The
    SelectConflictUpdatedRowsCommand is executed. Since there was a conflict, this should get executed. However since this example is forcing a ClientUpdateServerDelete, it will return no rows.
    3. The SelectConflictUpdatedRowsCommand is executed. Since the row was deleted, this does find the deleted server row.

    At this point the, ApplyChangeFailed event fires as normal and our code forces an update by using ApplyAction.RetryWithForceWrite.

    Now, the documentation for RetryWithForceWrite says it will, "retry with logic to force applying the change...To use this option on the server, use the @sync_force_write parameter and add support in the commands that apply changes to the server database."

    Based on this, I would expect it would set the @sync_force_write, and retry usp_CustomerApplyUpdate. Instead, in the trace I see that the framework actually called usp_CustomerApplyInsert (the apply insert script). I understand why it might be useful to use the insert script (since it has been deleted at the server), but is this stated anywhere in the docs?

    Furthermore, the
    usp_CustomerApplyUpdate stored procedure actually contains logic to check for the @sync_force_write bit. If selected, it checks if the row exists exists. If it doesn't exist, it performs an insert instead. The actual note in the code says:

            -- The row does not exist, possibly due to a client-update/
            -- server-delete conflict. Change the update into an insert.

    So which is correct way to handle this case? If we force a write in a ClientUpdateServerDelete, which will be called, our insert script, or our update script?

    • Moved by Max Wang_1983 Friday, April 22, 2011 9:34 PM forum consolidation (From:SyncFx - Microsoft Sync Framework Database Providers [ReadOnly])
    Wednesday, November 28, 2007 9:22 PM

All replies

  • Hi Eric,


    Well, the sample needs to be updated with late change that was done to the runtime to slightly change the behavior in this scenario. The update will become insert when the row on the server is deleted. This gives you better performance. When the insert command is call with force_write flag set, then the command should attempt to delete the row from the tombstone table and then insert (i.e. i does not need to check if the row is in the tombstone table or not). This is better than calling update with force_write flag set since there are two possibilities here; either the row is in the table and needs to be overwritten or the row in the tombstone table and needs to be deleted first.



    Thursday, November 29, 2007 4:47 PM