5 Replies Latest reply on Nov 1, 2016 5:07 AM by mikebeargie

    Sync Timing Issue


      I was wondering if anyone else has encountered this sync scenario (regardless, perhaps, of sync tools):


      Client A starts a sync. Each table's records are gathered in a loop. During Client A's gathering of records, Client B's sync completes and new records are now available for gathering. However, Client A has already gathered records from some of the tables. He'll miss the newly published records from Client B in the tables that he's already gathered. Worse case, he'll gather some child records and miss their parents.


      We're using EasySync and we see this. Perhaps the other solutions have a way to avoid this scenario? Thoughts appreciated.

      tia, Barbara

        • 1. Re: Sync Timing Issue

          This is called "Collision Detection Logic", same situation happens when two users try to lock and update the same record at the same time.


          Mirrorsync takes care of this automatically, and I'm sure other sync solutions have it built in as well.


          If I recall, when we used EasySync we ran into this, one solution was to write a customization that would set the last sync times for push/pull/full to fall back to when the initial call started, but to also somehow deal with the modification stamps on the server of any "pushed" records so they would not be re-downloaded in the next sync by that user.


          The other solution would be to create a custom sync log that forces users to wait for active syncs to finish before proceeding with their own sync.



          1) Sync A starts, record is created in Sync Log with empty finish time.

          2) Sync B starts, finds empty finish time, loops back to check again in x seconds.

          3) Sync A finishes and marks finish time in Sync Log.

          4) Sync B escapes loop when it finds Sync Log finished. Sync B proceeds to sync.

          • 2. Re: Sync Timing Issue

            Yes, EasySync. OK, "Collision Detection Logic" rather than Payload Timing Issue. Yes, we are thinking one sync at a time using flags. Thanks for the confirmation and suggestions.

            • 3. Re: Sync Timing Issue

              Since nobody is really supporting or developing EasySync anymore, I have moved on from using it. There are other frustrations (EG large data sets or images can crash iOS) too that you will eventually run into the longer you use it as well.


              The time savings (in installation, configuration and support) we’ve seen by using products like MirrorSync usually pays for the cost of licensing. MirrorSync is also much faster than EasySync.


              There are a number of sync products out there (EG GoZync, SynkDek, etc..) so it may be worth it to evaluate some of them if you have time.

              3 of 3 people found this helpful
              • 4. Re: Sync Timing Issue

                Thanks mikebeargie for the detailed answer.


                I am facing almost the same problem but somehow managed it as we do the Sync at mid-night when users are offline.


                I am more inclined towards other sync solutions as well but only thing in my mind is about the ease of debugging if something needs to be troubleshooted. Being proprietry solution, how much leverage does the 360 works give to troubleshoot if something goes wrong? Or is there any hidden charges involved if i just require free version of Mirror Sync for now (one server to one FM Pro Sync).



                • 5. Re: Sync Timing Issue

                  360works is well supported, their support team usually answers in under 24 hours and their documentation and support forums are quite thorough. They just released a new version, and I still highly recommend it.

                  1 of 1 people found this helpful