Issues with losing connection during sync job.

[jader1313]

Given the following scenario:
Using API for server-side synchronization.

In the client
-insert a record

• starts synchronization
  -before receiving the response from the API the connection is lost

In the server
-receives and processes the synchronization request
-observation: the table has a trigger and as soon as the record is inserted in the database, this trigger changes the content of a field.

In the client:
-raises a timeout exception
-when connection is resumed, start a new synchronization

In the server:
-receives and processes the synchronization request CHANGING THE REGISTRATION AGAIN, even if the registration on the server has been changed.

Question:
How can the client, which lost the connection with server, find out if the request was processed or not, in order to prevent a record from being OVERWRITTEN(re-sync) in the wrong way? Is there any ready-made way to deal with the above problems?

options = new SyncOptions() {
UseVerboseErrors = true,
BatchSize = 1000,
CleanMetadatas = false,
DisableConstraintsOnApplyChanges = true,
ConflictResolutionPolicy = ConflictResolutionPolicy.ServerWins };

Thanks

[Mimetis]

the table has a trigger and as soon as the record is inserted in the database, this trigger changes the content of a field.

It's one of your trigger ? or a DMS trigger ?

[jader1313]

My trigger

[Mimetis]

When a client send its batch files, they are applied on the server. It's basically the first step during the sync processus.

If everything is correctly applied on the server, the server will send back its own batch to the client (with all changes / resolved conflicts and so on)
And the client eventually applies the server batch locally.
And sync is ended.
Client marks sync as complete and update the last updated timestamp value.

If a client, for any reason, does not receive a response from server, it's considered as "failed sync" from the client perspective.
Even if the server correctly applies the client batch (and in your case, triggers your trigger)

And if a client does not receive a response, the sync is not completed, client does not mark the sync as complete, and will send again a new batch with the same rows on the next sync iteration.

And, as you mentioned, again the server will apply the batch, triggering a second time your trigger.

We can't mark the sync as complete on the client side, as we did not receive any server response, client can't know if any batch have been applied on the server successfully
Plus client did not receive its own batch to be applied locally.

Does it make sense ?

[jader1313]

Many thanks for the clarifications. This was the behavior I already thought was adopted, but I understand that there is a problem in the algorithm that must be addressed or we are not acting correctly:

The server applies the batch from the client(1), but the client(1) does not receive the response from the server and another client(2) changes the information. Until the client(1) communicates with the server again and resends the batch, another client(2) can receive, change and synchronize the same information with the server. This change will be LOST when the server reapplies the batch from the client(1).

I see two solutions:
1-On the server: when resynchronizing the batch from the client, check if that batch or part of it has not already been synchronized. Perhaps by timestamp or otherwise.
2-On the client: when you do not receive a response from the server, make a new request to the server so that it returns the status of that batch: not received, with error, successfully processed, ...

This problem is occurring frequently, would there be any way around it?

Our configuration is like "ConflictResolutionPolicy.ServerWins", when the server tries to reapply the batch from the client(1) and the information was changed by another client(2), shouldn't the server disregard this change?

[Mimetis]

Use case 1

• Client 1 makes some changes and then sync: Batch A (BA)
• Client 1 send BA to Server
• Server Applies BA and send back nothing (for keeping the sample easy to understand)
• Client 2 makes some changes and then sync : Batch B (BB) (and BB is updating same rows as BA)
• Client 2 send BB to Server
• Server tries to apply BB and raise a conflict. ServerWins says 'Server wins when conflict occurs' : BA is wining against BB
• Client 2 receive conflict resolved with BA
• Client 2 applies BA locally
• Client 1 has batch BA
• Client 2 has batch BA

Use case 2

• Client 1 makes some changes and then sync: Batch A (BA)
• Client 1 send BA to Server
• Server Applies BA and send back nothing (for keeping the sample easy to understand)
• Timeout exception is occurring.
• Client 1 did not receive any confirmation and sync is aborted (at last not mark as complete)
• Client 2 makes some changes and then sync : Batch B (BB) (and BB is updating same rows as BA)
• Client 2 send BB to Server
• Server tries to apply BB and raise a conflict. ServerWins says 'Server wins when conflict occurs' : BA is wining against BB
• Client 2 receive conflict resolved with BA
• Client 2 applies BA locally
• Client 1 has batch BA
• Client 2 has batch BA

[jader1313]

Use case

Client 1 makes some changes and then sync: Batch A (BA)
Client 1 send BA to Server
Server Applies BA and send back nothing (for keeping the sample easy to understand)
Timeout exception is occurring
Client 1 did not receive any confirmation and sync is aborted (at last not mark as complete)
Client 2 makes some changes and then sync : Batch B (BB) (and BB is updating same rows as BA)
Client 2 send BB to Server
Server Applies BB and send back nothing
Client 1 send BA to Server(connection to server reestablished)

Server Applies BA (overwriting BB) WRONG
Client 1 has batch BA (should end with BB) WRONG
Client 2 sync(receive BA) WRONG
Client 2 has batch BA(error) WRONG

Sorry, we were using version 0.9.7 on the server. Updating to 0.9.8 resolved the issue.

Thanks

[Mimetis]

I think you can surely upgrade to version 1.0 beta