Synchronization via automerged snapshots and changes sets

Nobody has claimed this yet.

Another way to solve the need for synchronization can be done via delaying of write operations to database.
Each uncompleted and some completed (the most resent transactions) can be still stored in small change set.

Each read operation should give a merged result of the saved database snapshot and the change set (that can contain changes from both completed and uncompleted transactions).

Once the user is ready to do some write operations. The result of each write operation can be temporarily stored in one of change sets. If the change set is shared and the transaction is completed, the changes are immediately become available to all subscribers to that change set.

It should be possible to combine/merge as many database snapshots and change sets as need.

So while recent changes are still written to the database, old snapshot remains unchanged, but user still have access to all recent changes that are stored in change set. Once a new snapshot is ready, it can be instantly swapped with the old one.
Each time, reducing the overhead of dynamic application of current change sets on top of current snapshot.

Each change set can be stored in the Doublets data store.

Each thread can have its own copy of all change sets available to it.

So synchronized data is not shared, but duplicated for each thread.
Snapshot swap is done fast using atomic operation.

So no two threads will try to write to the same region of memory at the same time.
The best synchronization is the absence of synchronization.

The only challenging part is to implement some kind of lock free queue to stream changes to all interested threads.

If such an architecture is possible and works, it should be easy to scale it to any size of distributed data store.

Each data node store will have its own current snapshot, that will be regularly updated with all changes streamed from other nodes. It may be even possible to have no centralized master server node, all nodes can be equal, and all the nodes eventually will have all the same data.

We can start with network of nodes with absolute trust. So every change broadcasted by any node in the network will be applied to all nodes. The nature of delayed write is very useful in the distributed environment. We can set some threshold of that delay, so we can start write changes to the snapshot only when for example one minute have passed after transactions have committed, and all conflicts if present already solved, and it is not possible that one of the changes are still traveling through the network of nodes.

Each conflict can just trigger the uncommitted transaction to fail. So if any node notices the conflict it broadcasts the message about it and all affected transactions are marked as failed. The client (user) is notified about it, and he can try to repeat the transaction or, if set to auto-repeat, the transaction can be moved to the end of the queue for repeated application on nodes.

Related to https://github.com/linksplatform/Data.Doublets/issues/243

https://en.wikipedia.org/wiki/Read-copy-update

Start by reading related issue #243 and the linked Read-copy-update background. Define whether the proposed snapshots, change sets, lock-free queue, atomic swaps, conflict handling, and distributed replication are feasible in Data.Doublets, then document a decided scope and success criteria; the issue names no files or tests to run.

Written by the indexing model from the issue text.