Avoid synchronization while an synchronization is already in progress.

[lestcape]

I want to know if will be possible avoid a synchronization while a synchronization is already in progress.

We don't let modify a case when is complete. So, to us is supposed that if we have a case that is not in partial_save_mode in CSWeb we can not recive the same case (same GUID) after it is store, but we are receiving it. So, to us that means that the interviewer send twice the same case, probably because a connection problem.

So, i want to know if can be possible avoid to send a new synchronization while another is in progress. Is this a bug in CSPro or it's done in that way because of any particualr thing?

[josh]

I'm not sure I fully understand your question. CSWeb is designed to handle synchronizations from multiple users at the same time. If a user modifies a case then it will be uploaded to the server on the next synchronization. It is up to your application to prevent users from modifying the case once it is completed.

[lestcape]

Thanks @josh. Yes, your answerer is not relate with my question at all. Suppose that i have just one CSPro client of my CSWeb server. He is using one only device (the device 0000000) and it have one case (case 001 with guid 0000-0000-0000-0001) in his device. He already finished his case and then push the synchronization button and send that case.

The case is received in the server side (CSWeb) twice, as it can be see in (table cspro_sync_history):

1- With the revision 1 at time 08:00:00 for the device 0000000 caseid 001 guid 0000-0000-0000-0001
2- With the revision 2 at time 08:00:03 for the device 0000000 caseid 001 guid 0000-0000-0000-0001

The question is how this can be possible? How i can received the same case twice with an interval of 3 seconds maximum, from the same device with the same guid and the same caseid?

To us that means that the interviewer send twice the same case.

But we want to know why and if this can be avoided some how.

EDIT: The CSPro application is already preventing a case modification when it was finished. But anyway, the user have not the time (less than 3 seconds), to modify the case. This is a problem that occurs when the case is send and is unrelated with the power that have the user to modify or not the case.

Again thanks.

[lestcape]

Probably is because the user use the shortcut (Ctrl+Shift+S) to send the info and he hit several time the shortcut, sending several times the same info.

This can be prevented somehow?

[josh]

Are you seeing the same case twice in the table that has the same name as your dictionary? The table with the same name as the dictionary is where the data itself is. The sync_history table just shows which devices have synced with the server. It does not show which CASES have been synced. There will be an entry in the sync_history table every time a device syncs with the server even if it does not send any cases. If your client has one case and syncs twice in a row without modifying the case then you will get two entries in the sync_history (one for each sync) but only one entry in the table with the dictionary name. One the first sync, CSPro will send the case. On the second sync it will not send anything but it will still contact the server causing an entry in the sync_history.

Also if you are using BOTH as the sync direction then you will actually get two entries in sync_history: one for the upload and one for the download.

[lestcape]

Thanks one more time @josh. I will answer your sentences one by one only to show you that i fully understand the process (because, yes the problem reside in the implementation level). I migrate CSWeb 7.0 from MySQL to PostgresSQL some month ago and i implement a mechanism in CSWeb 7.4 to extract the questionnaire to queryable tables on fly when the data are received in CSWeb (i know this is planed to be included in 7.5).

Are you seeing the same case twice in the table that has the same name as your dictionary?

No, of curse not, both revision that we received have the same guid (the primary key of that table you mention).

The table with the same name as the dictionary is where the data itself is

Yes sure, i know.

The sync_history table just shows which devices have synced with the server. It does not show which CASES have been synced.

Yes, but in the sync_history table we have the revision value and we can search the data that belong to that revision in the table that has the same name as your dictionary. Using as a dictionary name the name of the dictionary that have the same id in the cspro_dictionary table than the id on the sync_history.

It does not show which CASES have been synced.

This is false, it show the CASES that have been synced, but only in the moment that they are received and if you use the revision column to join both tables (the cases and the history). In the next send, the revision is override by the last one in the table that have the dictionary name, but in the history table is preserved both revisions.

There will be an entry in the sync_history table every time a device syncs with the server even if it does not send any cases

Yes of curse.

If your client has one case and syncs twice in a row without modifying the case then you will get two entries in the sync_history (one for each sync) but only one entry in the table with the dictionary name.

The problem I detected is here, because what you said is true, but i can easy detect if the synchronization included the caseid or not (using the revision). The problem is that the second synchronization at same at the first is including the same caseid and the case was not modify. So, it can not be send again to the server following the CSWeb/CSPro logic.

One the first sync, CSPro will send the case. On the second sync it will not send anything but it will still contact the server causing an entry in the sync_history.

Exactly, this is what is not happening some times and what i'm reporting as a possible bug here. On the second sync, CSPro sometimes also send the case when is supposed it need to send nothing.

Also if you are using BOTH as the sync direction then you will actually get two entries in sync_history: one for the upload and one for the download.

We actually only used one direction and that is from client to the server.

[lestcape]

To clarify why we need that:

We need a fix for that, because in the process where we are transforming the data to a queryable tables on fly, we also have a mechanism that when we received the same data (a duplicate case), we report it to the supervisors by email. But how is not really a duplicate case (because is the same case twice) we are reporting to the supervision a false positive duplicate case.

That is not amusing to the supervisor, because it was lost time tries to find a duplicate case that does not exist.

[josh]

Can you send the sync.log from the client when this happens? In the sync.log it will show the synchronizations and the number of cases that were sent.

It is not possible for two syncs to run at the same time. The code that does the synchronization is single threaded so they must be done in sequence.

Is there anything else you are doing on the client side that could cause the case to be modified in between the two syncs?

[lestcape]

Thanks @josh, but find the client log will be really difficult to us. I will try anyway.

It is not possible for two syncs to run at the same time. The code that does the synchronization is single threaded so they must be done in sequence.

Asynchronous and single-threaded at same time is possible (https://codesthq.com/asynchronous-and-s ... vent-loop/). You are probably requesting things to CSWeb in an asynchronous way (using an asynchronous library to make an HTTP Request). While this is happening, CSPro is already active to handled new events and probably this can be create a new asynchronous HTTP Request.

Is there anything else you are doing on the client side that could cause the case to be modified in between the two syncs?

We are using the default synchronization mode (the one that is build in CSPro), not our own logic to synchronized things. So, i can not see what we can do to cause this, but i also can not discard a problem in our side and that is why one of my questions is why this could happens.

[josh]

We are making only single threaded, synchronous http requests on our end. The http library we are using is NOT asynchronous.

The only scenario I can imagine where the request would be made twice would be if the first request succeeded to update the data on the server but for some reason the client received a network error like a connection timeout or something so it never got the confirmation from the server. In that case, for certain network errors, the client will retry the request. If the client does not receive a successful result from the server then it does not mark the cases that is sent as synced and would send the same case again on a retry. We have never this happen in practice but it is at least theoretically possible. It would certainly show up in the sync.log file as all the network errors and retries are logged there.

Is this something that happens consistently or is it only happening for certain users or is it intermittent?