Concurrent data access conflicts

Data sync conflicts can occur and needs to be treated by the client application.

Principle

The concurrent access is similar to a source versioning system like GIT: The first client sending its changes to the central database wins.

As general rule, each client must be as much as possible up to date with the central database.

The more the client is behind the central changes, the more conflicts will need to be resolved.

If DB Sync client users/apps are working on different sets of rows defined by the data filters, no conflicts can occur.

First updater wins

When several clients modify the same data rows, the first client (user/app pair) requesting a data sync will succeed.

If a second client sends changes on the same data rows, conflicts are detected by the DB Sync server, and the whole sync process fails for this second client.

The second client must then cancel the current sync process and ask for a new sync, rework or drop the changes it wanted to send, and proceed with another sync.

The following is an example of a possible conflict:

  1. Client C1 and C2 are in sync with central database.
  2. C1 makes a change on row 1 and deletes row 2, then syncs the changes to the server.
  3. C2 makes a change on row 2 (deleted by C1), and sends the change to the server.
  4. The sync fails because of changes of C1. From this point, C2 must save its local changes (done automatically with the stash tables), then sync with the server to pull recent changes, apply again local changes (resolving conflicts) and re-sync with the server.

Field-wise row changes

When using field-wise updates, changes can be made by several clients on the same row without conflict, as long as different fields are modified by each client. The following subsequent changes can be done without conflicts:
  1. Client C1 changes cust_name, cust_birthday of customer row 1.
  2. Client C2 changes cust_addr, cust_city of customer row 1.
However, the following change sequence would fail for client C2 because both C1 and C2 want to change the cust_city field:
  1. Client C1 changes cust_name, cust_city of customer row 1.
  2. Client C2 changes cust_addr, cust_city of customer row 1.
It is reccomended each user/app is synced regularly with the central database to avoid missing changes in the central database.

If DB Sync client users or apps are working on different sets of rows defined by the data filters, no conflicts can occur.