One of the key topics related to Oracle Offline Persistence toolkit - submitting client changes to backend when data conflict exists. If data was updated on the backend, while client was offline and client wants to submit his changes - we inform about the conflict and ask what client really wants to do. If client choose to submit changes, this means we should push client changes to the backend with the latest change indicator.
There is a special case, when client updates same data multiple times while offline - during online sync we need to make sure, change indicator will be retrieved in after sync and applied in before sync listeners, to make sure subsequent requests execute correctly. Check my previous post about before request sync listener - Oracle Offline Persistence Toolkit - Before Request Sync Listener.
Example - let's update a record and submit change to the backend:
Assume another user is offline and updates same record:
User updates same record again, before going online. Now we will have two requests in the sync queue:
Once going online, sync will be executed and we will get conflict for the first request (same row was updated already by another user). At this moment, after sync listener will get info about conflict and will cache latest change indicator value returned from backend. If user decides to apply his changes, requests is removed, new request is constructed with the latest change indicator value received from backend and this request is inserted into sync queue:
If same record was updated multiple times, second request will fail too - because this request wasn't updated yet with latest change indicator:
Assuming user decided to apply changes from the second request too, we will update request with latest change indicator and submit it for sync. In after sync listener, change indicator value stored in local cache will be updated.
Successful sync with change indicator = 296:
New change indicator value will be retrieved in after sync listener and applied in before sync listener for the second request, updating same data row:
Here is the code, which allows user to apply changes to backend. We remove failed request, update it and create new request in sync queue, resuming sync process:
Download sample code for the described use case from my GitHub repository.
There is a special case, when client updates same data multiple times while offline - during online sync we need to make sure, change indicator will be retrieved in after sync and applied in before sync listeners, to make sure subsequent requests execute correctly. Check my previous post about before request sync listener - Oracle Offline Persistence Toolkit - Before Request Sync Listener.
Example - let's update a record and submit change to the backend:
Assume another user is offline and updates same record:
User updates same record again, before going online. Now we will have two requests in the sync queue:
Once going online, sync will be executed and we will get conflict for the first request (same row was updated already by another user). At this moment, after sync listener will get info about conflict and will cache latest change indicator value returned from backend. If user decides to apply his changes, requests is removed, new request is constructed with the latest change indicator value received from backend and this request is inserted into sync queue:
If same record was updated multiple times, second request will fail too - because this request wasn't updated yet with latest change indicator:
Assuming user decided to apply changes from the second request too, we will update request with latest change indicator and submit it for sync. In after sync listener, change indicator value stored in local cache will be updated.
Successful sync with change indicator = 296:
New change indicator value will be retrieved in after sync listener and applied in before sync listener for the second request, updating same data row:
Here is the code, which allows user to apply changes to backend. We remove failed request, update it and create new request in sync queue, resuming sync process:
Download sample code for the described use case from my GitHub repository.
No comments:
Post a Comment