none
Bandwidth Throttling with Batching + ConflictHandling with bidirectional Changes RRS feed

  • Question

  •  

    Hello,

    I am currently working with the Microsoft Sync Framework in order to create a local data set for faster/offline access. The synchronization progress was easy to implement, but now I meet problems whose solutions are essential for my application.

    • I have read that the batching size cannot be smaller than a row's size ("During a synchronization session, if a single row is greater than 110% of the size the session terminates with an exception.") I store data that can have a size of 100MB but a cache size must not be this big. This is due to the fact, that I want to have small batching packets to match a certain upload/download speed by throttling the whole process with some thread sleeps whenever a packet is spooled. So you see that its important for me to know, if there is a way to set a batching size smaller than my row size.
    • As I am using bidirectional synchronization, a costumer is able to change the local database. These changes must be uploaded to the global database without confliting with other changes. How can I handle such an error? Is it related to the TrackingColumn?

    Thanks for your help!

    Marcel Bonzelet

    Monday, July 12, 2010 10:03 AM

Answers

  • to answer your question, afaik, no, you cannot set the batch size lower than the rowsize. A row is the smallest unit of change in Sync Fx. You can't tell Sync Fx to send the first 3 columns of the table because that's the only size that can be accomodated by the batch size and send the remaining columns on the next batch and let Sync Fx assemble the row.

    To handle the conflict, you can subscribe to the ApplyChangesFailed event of the remote provider (am assuming this is your server).

    • Proposed as answer by Jesse L - MSFT Tuesday, July 13, 2010 12:58 AM
    • Marked as answer by bonzy Tuesday, July 13, 2010 7:23 AM
    Monday, July 12, 2010 11:38 AM
    Moderator

All replies

  • to answer your question, afaik, no, you cannot set the batch size lower than the rowsize. A row is the smallest unit of change in Sync Fx. You can't tell Sync Fx to send the first 3 columns of the table because that's the only size that can be accomodated by the batch size and send the remaining columns on the next batch and let Sync Fx assemble the row.

    To handle the conflict, you can subscribe to the ApplyChangesFailed event of the remote provider (am assuming this is your server).

    • Proposed as answer by Jesse L - MSFT Tuesday, July 13, 2010 12:58 AM
    • Marked as answer by bonzy Tuesday, July 13, 2010 7:23 AM
    Monday, July 12, 2010 11:38 AM
    Moderator
  • Hi JuneT,

    thanks for your reply. This means I cannot use the whole framework just because of the fact, that the batchsize would be too high for my application to work. As single columns of mine might be bigger than 10MB, the little steps (about 1-10KB) I want to go through the synchronization progress are not possible with Batching.

    Maybe you know about another way of stepping in the synchronization? In general, I want to lower the network usage for the costumer to assure that he is still able to use his PC during a hidden synchronization progress. I could not find any way to do this, so I thought about pausing the sync with Thread.Sleep() in order to give other processes precedence. Maybe there is another way of lowering the network usage?

    Still I don't really know, if this question belongs here.

    Monday, July 12, 2010 12:33 PM
  • JuneT is correct, if the row is greater in size than the batch size then it will not work.  Although given that you have data larger than the size you want to transfer at a time you are in a bad position regardless of any limitations in the sync framework.

    Tuesday, July 13, 2010 12:58 AM
  • Good morning

    and thanks for your Answer, Jesse. And that does mean, I am not able to use the sync framework anymore. When I found this framework, I was happy due to the fact, that I don't have to do it on my own. This limitation is a bit surprising for me, but it makes sense. Again I have to say thank you two and have a nice day.

    Tuesday, July 13, 2010 7:22 AM