4 Replies Latest reply on Feb 27, 2015 6:23 AM by Nedzad Imamovic

    partial syncronization issue

    Nedzad Imamovic



      we have deployed app for field sales where we have sales personal taking orders at customer's sites. In some areas we are experiencing really bad GPRS connectivity and often rhoconnect transfer gets broken while syncing data. Result is in dispatching module where orders are received that we have order with heards without items (header contains customer info, items what is ordered) or header and only partial list of items (if item list is long and transmission gets broken we have like some items transferred and some left out).


      This is something we have to cleanup manually now. Question is: Is it possible to tell Rhoconnect to actually delete partial transmission and start all over again to secure data integrity ?



        • Re: partial syncronization issue
          Kutir Mobility

          Hi Nedzad, I do not believe there is a built-in way to do that at this time - RhoConnect client updates are not atomic from the point of view of your application and what you are seeing is the default behavior; you will have to handle these discrepancies on a case-by-case basis (hint to the Zebra Rho team: adding rollback capability would be a really nice addition, dealing with this scenario in application code is a pain).


          How you react to this depends on your application: one possible approach is to let the user know when there is a synchronization problem and not let them perform certain actions until they complete one full sync cycle. You could also leverage bulk sync, which guarantees that all records in a partition will be present (but you may have to change how you deal with client updates locally so as not to lose user data). Another option is to mark your models on the server so that the header row knows how many item rows it should expect and notify the user if there is a mismatch. Keeping track of this is another pain and it can get ugly and complicated very quickly depending on your application.


          There must be more ways to deal with this (you could keep track of which rows came from a successful sync cycle and which did not, then delete those manually, but you would also have to make sure to update the changed_values table so that it does not try to delete those rows from the server. It's not clean but it might work).


          Hopefully that will get you pointed in the right direction at least.


          Kutir Mobility

            • Re: partial syncronization issue
              Nedzad Imamovic

              Hello Javier,


              so, do you know if Rhomobile is planning add atomic stuff to Rhoconnect? Without this, it is going to be killer-effort to take care of this on bad GPRS connectivity. Also, is there some code samples about monitoring one fully sync cycle or taking care of this within the code ?


              Thanks for clarfication!



                • Re: partial syncronization issue
                  Pietro Francesco Maggi

                  Hi Damir,

                  RhoConnect is inherently asynchronous in its sync behaviour to provide maximum scalability.


                  Data sent from clients are added to a queue and the server process them in batches, asynchronously.

                  It's not an easy task to add atomic operation to this kind of architecture and I'm not sure that it can be implemented without a deep re-architecture of what we've.


                  Javier suggestion to manage this at the application side is currently the best option.



                  1 of 1 people found this helpful