Hello Experts,

I have a mobile app in which I am supporting offline mode.I used offline synchronization given by platform that will store approx.60000 records in local storage from server entity.

My question OR doubt is that during offline synchronization process (when data inserting from server to local entity) if someone on device goes offline or intentionally switch off device in case of incomplete synchronization process(Sync not completed), in that case TRANSACTION will be rollback automatically.

Example:-In first attempt 5000 records inserted(from server to Local entity) then device goes offline then again come online and synchronization started again this time synchronization successfully completed and this time whole 60000 records inserted in local entity.
My doubt is ,how many records will be available in local entity 65000 OR 60000?

Hi Salman,

Afaik the Local Storage doesn't support transactions, so there will never be a rollback of any kind. Your synchronisation will always have to deal with partial updates, you should never just insert records without checking for duplicates or some other strategy. So if you end up with 65,000 records, that's a problem with your synchronisation code, not a problem of the Platform.

Kilian Hekhuis wrote:

Hi Salman,

Afaik the Local Storage doesn't support transactions, so there will never be a rollback of any kind. Your synchronisation will always have to deal with partial updates, you should never just insert records without checking for duplicates or some other strategy. So if you end up with 65,000 records, that's a problem with your synchronisation code, not a problem of the Platform.

Hi Kilian,

Thank you for response.I agreed that not platform issue.

So to handle the above problem what will you suggest?
1.Need to Clear all the Local data first then insert from beginning?(this will be required less effort as we already done most of the functionality in mobile app)
2.Need to check duplicate records using Id or something and not insert already exist data in local entity(it will take more time as we have around 20 Local entity)
3 Any better way to handle this?


FYI-We already applied the Logic to get the records from Server to Local(vice-versa) using the LastSync time parameter in offline sync.So in that way we will only take those records that are latest modified on server OR local after LastSync time.(Sync is very fast that way.)

Hi Salman,

First, check the documentation starting here. Use the left-side menu to read the other topics about offline sync as well. It describes various strategies for syncing.

In your specific case, I would advise you to sync only the delta. So keep a date/time of last successful sync (update it after syncing), send that to the Server and have the Server return only the records that are modified or added since the last sync. To sync back to the Server in case you allow editing local records use the same strategy: only sync those records that have been added or modified.

Kilian Hekhuis wrote:

Hi Salman,

First, check the documentation starting here. Use the left-side menu to read the other topics about offline sync as well. It describes various strategies for syncing.

In your specific case, I would advise you to sync only the delta. So keep a date/time of last successful sync (update it after syncing), send that to the Server and have the Server return only the records that are modified or added since the last sync. To sync back to the Server in case you allow editing local records use the same strategy: only sync those records that have been added or modified.


We are already doing below as per your comments.problem is to handle the Transaction in offline sync when its failure for first time.As Transaction not applied for local offline sync.

In your specific case, I would advise you to sync only the delta. So keep a date/time of last successful sync (update it after syncing), send that to the Server and have the Server return only the records that are modified or added since the last sync. To sync back to the Server in case you allow editing local records use the same strategy: only sync those records that have been added or modified.


Hi Salman,

If it's a first-time sync, and you are expecting to sync a lot of records (as in your case), and sending all records at once is not an option, I would make this a special case in the sync routines, and sync in smaller batches, first syncing everything regardless of any server-side updates (and keeping track of progress), next performing "normal" incremental sync, but with a last sync date that's equal to the start of your initial sync, so everything changed during the initial sync will be synced as well.

Since per batch, all data needs to be received before you can process it, it's not possible to process a partial batch, so unless storing the batch goes wrong somehow, you needn't worry about transactions. Of course, to make it extra robust, you might need to keep track of partial batches, but it depends a bit on what you need.