Batching on Upload RRS feed

  • Question

  • Hi,

    I read that with Sync Framework 2.1 batching is possible during synchronization but only on download not upload. Is this true or am I misunderstanding something? If this is true is there a good reason why? If I am just misunderstanding then could someone provide a link pointing to some information?

    If it helps with explanation I am using SQL Express on client side and SQL Server 2008 on server.

    Thanks in advance for an help.


    Sunday, March 6, 2011 3:46 PM


All replies

  • I have a wcf setup SQL Ex <> SQL Ex, with batching both ways if necessary. its based off of the example in the gallery.
    Monday, March 7, 2011 2:25 PM
  • That would be a great help if you are willing to provide a sample or even just point me towards where you found the info it would be much appreciated.
    Monday, March 7, 2011 2:32 PM
  • Monday, March 7, 2011 3:37 PM
  • Thanks for the help.
    Monday, March 7, 2011 4:25 PM
  • Hi,

    I know this is already answered but because my new question is related I said I would ask here rather than start a new thread.

    I have been looking through the example above and while it does implement batching on upload it is an N-tier architecture. Preferably our group would like to go with a 2-tier architecture (something I forgot to mention before). Is batching on upload possible with 2-tier or does it have to be N-tier?

    It has also been suggested that we might need a file syncing system for a separate function in the project however we want the database sync to take precedent. I was thinking the file sync could be placed in a lower priority background thread while the db sync could be kept in the main thread(or in a second thread with the file sync in the third thread). Any suggestions as to the most efficient way to implement this would be welcome.

    I should say as well that this application is being developed for net books which may spend a large amount of time without network connection(and a bad connection when they do have it) so the updates may be large which is why we would like to implement batching.


    Thanks again for your help.



    Thursday, March 10, 2011 2:44 PM
  • batching should work just the same on 2-tier scenarios. check out How To: Deliver Changes in Batches  in the docs.
    • Proposed as answer by Ganeshan Friday, March 11, 2011 9:48 PM
    Friday, March 11, 2011 12:45 AM
  • Thanks for your help JuneT.
    Friday, March 11, 2011 8:44 AM
  • Hi David,

    Batching on upload is supported in SyncFx 2.1 and should work.

    To answer the second part of the question, are the files and the data in the database related somehow? Like, the file names are referenced in the database and not having the files before the database is sync'd would lead to a bad UX? These are parameters you would need to consider. I do not believe the way you implement your threads is as important as what data you want on the server and in which order. Are you assuming that the lower priority thread would never run until the database sync completes? This is not necessarily the case in a multi proc system - both threads may run concurrently.

    Hope this helps!

    SDE, Sync Framework - http://www.giyer.com
    • Proposed as answer by Ganeshan Friday, March 11, 2011 9:48 PM
    Friday, March 11, 2011 9:48 PM
  • Hi Ganeshan,


    Thanks for the reply. I managed to get the batching implemented and I think I have decided how I am going to implement the file sync. The data in the database and the files have no relation to each other. The file sync is a secondary aspect to the project used for sharing files between users. The reason I wanted to keep the file sync on a lower thread is because the data sync is so much more important I want to insure it takes priority especially with the poor internet connection. I have lots of options as to how to do this I may simply do it as an "upload button" type situation where the user clicks the button selects the file and hits upload. But I would be interested to hear how you would implement the feature if you would do it differently. A different perspective is always helpful :)



    Monday, March 14, 2011 8:43 AM