Multiple Local Replicas RRS feed

  • Question

  • I am thinking of trying Microsoft Sync Framework to synchronise both some slow changing persisted data (transactions, logs, reference data), and some fast changing non-persisted data (device states, etc). Each of these data types have different requirements when it comes to frequency of updates and priority. Two questions:

    1. Is MSSF suitable for rapid (multiple per second) polling for small sets of rapidly changing data?
    2. I am concerned about fragmentation of the knowledge, as a lot of updates are likely to be deferred anywhere from a few minutes to a day if they are lower priority (e.g. log transfers may occur only nightly, but local transasctions and device information need to be transferred almost immediatly). We will also be filtering a lot of data based on where it originated and the locations it affects. I was wondering if using a different ReplicaID for each set of data would prevent the knowledge from becoming heavily fragmented. However it is not clear to me how local knowledge for multiple local replicas (e.g. one for persisted data and one for in-memory data which is lost when the application is closed) could be updated seperately with only the updated knowledge that belongs in that replica. There are no methods on SyncKnowledge that allow knowledge for specific replicas to be retreived/removed/etc.

    The idea of using MSSF for both the slow persistsed and fast non-persisted sync seemed an elegant solution, but that doesn't mean its the right one. I am also considering using a different mechanism for the faster sync updates. However that still leaves some persisted data that we wish to provide different priorities/schedules/filters for synchronisation, and hence the potential for knowledge fragmentation.

    Still fairly new to MSSF and trying to get my head around much of it.

    Friday, August 10, 2012 1:45 AM

All replies

  • Sync Framework requires sync providers to work against the specific stores you want to sync. have you given thought to what providers out of the box will work against your stores? if there is no provider, are you up to writing one?

    to answer your first question, based on experience, No. sync is not just about polling for change data. at a minimum, you require functionality for change tracking, change enumeration and change application, not mention, conflict resolution. thats a lot of work if you're eyeing near-real time performance.

    Friday, August 10, 2012 6:11 AM