drewmccormack
commented
10 years ago We added a final check to make sure the merge event has a unique revision number just before it saves, and if not, it gets deleted and the merge fails. This should handle the unlikely collision with a save.
There was fear that saving the merge child context would overwrite changes in the parent that may have been made due to a save, but this is not a problem: the only overlap is in the global identifier —> object change relationship, and it turns out to-many relationships get merged when you save a child context.
Is there a potential for data loss? For example, if a save occurs when a merge is half way through, the merge may already have determined its revisions. The save would mess up the revisions. So we need to make sure that a merge is robust enough to handle a save injected in the middle. This could be as simple as checking if the revisions have changed since beginning the merge, or listening for will-save notifications and terminating a merge if one is detected.
A better approach would be to make a more formal serialisation for the event store, including child contexts. We could use a lock, but a queue is probably better. Basically, user code would be required to queue any operations that could make changes to the event store or a child context. This way, there could not be multiple tasks changing things.