Hi,
I developed an ppc application, where i am using web service for synchronisation, but here i am getting lot of problem while handling conflict management.
Please suggest me how to manage conflicts, using web service.
Thank you,
Prashant
Perhaps the easiest way to ensure that the unit of work that each mobile client is performing is guaranteed unique and avoid conflicts at synch time is to assign each data row a uniqueidentifier or GUID as it's PK and introduce the concept of a last changed datetime so that any changes to a unique data row from more that one mobile user can be applied on the server in the proper chronological order. Even this approach will break down in some synchronization scenarios, so web services are really best when data that needs to be operated on by mobile users can be strongly partitioned from other users or server-side changes to the data while on device.
-Darren
|||Hi,
Thanks Darren for your reply,
I want to validate on column level of conflicts, i have given each row a different guid, but column was conflicts i am not able to handle.
Please suggest me.
|||it's pretty hard to implement your own column level tracking of a single row that can be in multiple states across a population of mobile users. Merge replication uses 3 GUID columns, logic in the Server Agent, and tracking in the Distribution database to pull this off. I guess what I would do is get your web service synch algorithm down to working well with row-level changes and then try to eliminate scenarios where conflicts can occur. You may have to maintain some metadata about "who-pulled-what" on the server to do this. If your problem domain is such that more than one mobile user can pull the same row, you allow any or all of them to change that row (and perhaps the row is changing on the server as well), then you are biting off a pretty complex software engineering challenge to prevent the possibility of conflicts using web service synch. Start out simple and try to eliminate the scenarios where conflicts can occur by strongly partitioning data as much as possible. Column level tracking is nice in that it reduces the amount of data that has to be sent back and forth, but I wouldn't bite that off until you have a simple PutUpdates and GetUpdates working at the table and row level.
-Darren
