Locking and Coherence
What are Conflicts?
On a network without Synctus, staff cannot normally edit the same file at the same time.
For example: if Alice is working on a Word document and Bob tries to open it, then Bob will be stopped with a warning telling him that Alice is editing the file. If Bob had been permitted to open the file anyway, then the changes made by whoever finished first would be lost. This is sometimes described as a lost update.
Other file replication systems do not extend this locking mechanism between sites. Instead, they allow these simultaneous changes to occur and then try to resolve any conflicts later. When resynchronisation takes place and a conflict is found, then either one version is deleted, or a user is prompted to fix the problem manually.
This means that either users have to either be trained on understanding synchronisation conflicts and on how to resolve them by hand, or IT support have to work harder sorting out conflicts individually as they occur.
Preventing Conflicts
Synctus is different. It ensures that conflicts cannot occur. It does this by ensuring that a lock is held before a file can be opened for writing.
Synctus maintains a separate lock for every file in the system. Each lock can only be present at one site at a time. When a user opens a file for writing and the lock is not present, the lock is transferred first. A lock transfer takes only a few bytes of traffic and just one round trip, so is typically so fast that a delay cannot be perceived.
By making sure that a lock is not transferred to a site until that site has the latest version of the corresponding file, synchronisation conflicts cannot occur.
This means that different files can be open at different sites at the same time, but the same file cannot be open for writing at more than one site at a time. Staff can still open the file read-only from any office as usual. This is the same behaviour as a system without Synctus in a single office—so no changes to working practices or staff retraining is required.
