In several articles, I introduced the SnapShot (snapshot method) and the "Synchronize only new and incremental changes" synchronization methods and a rough analysis of the corresponding build files. Get down to the topic today and talk about the conflict detection and processing of MSF.
The main point of the conflict (Conflict) is that when the client and server-side data are cud, an error occurs during the synchronization of the data being manipulated, such as the usual constraint violation (primary key duplication), and the same row changes on multiple nodes (clients) at the time of synchronization. Or the server side deletes the row and the other nodes update the row there is a conflict. Of course, you should avoid conflicts when designing your applications (for example, by filtering rows and columns), because conflict detection and resolution can increase application complexity, increase processing burdens, and network traffic.
The current MSF itself provides some basic support for the problem of conflict. The following are the basic types of conflicts that it defines (Conflict.conflicttype), which include: Clientinsertserverinsert: Both the client and the server are inserting rows with the same primary key value. This operation caused a primary key conflict.
Clientdeleteserverupdate: The client deleted the row for the server update.
Clientupdateserverdelete: The server deleted the row for the client update.
Clientupdateserverupdate: The same row was updated by the client and server.
Errorsoccurred: A client or server store (typically a database) throws an exception when the change is applied.
Unknown: The provider can classify all conflicts encountered while the client is synchronizing, but the server cannot provide the program when synchronizing.
If you want to intercept a conflict, you can do so by applychangefailed event bindings to the corresponding Syncprovider object, such as the following example code:
syncclientsyncprovider.applychangefailed+=
New Eventhandler<applychangefailedeventargs> ( syncclientsyncprovider_applychangefailed);