Step 5: Synchronize data in domains between sites

Whenever modifying CRUD operations on domain entities are performed on a domain-serving work site, the data first goes to the SDC, and then, if successful, is sent to the MDC, from where it goes to the domain’s DBMS_.

For this purpose, there is a synchronization process initiated by each SDC. Just in this process, the accumulated outstanding changes are sent to MDC at the beginning, and only after that the full synchronization between SDC and MDC is done, where MDC is the source of information. Once every 20 seconds, each site performs a synchronization procedure between SDC and MDC MDC.

Consequence: an administrator modifies an entity via WS of a work site, SDC accepts the changes and sends them to MDC, but it fails. In this case, the administrator sees that the entity has changed, and 20 seconds later the changes are rolled back, because MDC was the source of information during synchronization, and these changes are not there.

SDC directly communicate with each other only in the framework of proxying requests from one site where the domain is not served to another where the domain is served. This is degenerate communication.

A domain can be served on several work sites. The configuration file (step 1) is responsible for this configuration. Different roles exhibit different behavior patterns in connection with multisite domain service. Let’s look at how the SDC behaves in this situation. It turns out, all things considered - its behavior is a consequence of its synchronization process with MDC. Whenever one of the sites in the SDC changes some entity. some entity, that change is first pushed to the MDC and then then from there it is synchronized to the other SDCs (see figure). In this case conflicts are also solved by MDC and its transactionality: creation of an item with the same identifier from different sites - remains the one who first ran to MDC, when changing one entity - remains the one who last ran to MDC, deletion is indifferent to the sequence, but has priority over modification of an entity in any order of operations. Obviously, it is impossible to get an infinite cycle of synchronization of several sites. It is worth keeping in mind that synchronization of domain entities between the two sites occurs in intervals of 20 seconds. That is, mostly sites will be synchronized within 20 seconds. In some rare cases synchronization time may increase several times.

In this case for the administrator everything looks the same as in step 1. And internally, the changes are applied to the current site, and stored in the submit queue. SDC makes periodic attempts to send them exactly in the sequence in which they were applied. There is a limit of 10000 modifying CRUD_requests per site on the size of this queue, after which _SDC starts refusing to execute them.

As a verification exercise, try to describe the steps of the process yourself up to the end of synchronization and find out the states of the entity being changed at these sites at each step.