Please let me know if this thread doesn’t belong to its current category.
I was wondering how concurrency works in Dynalist. From the looks of it, and also judging by some reports of data loss, it’s a last-writer-wins on a file basis, right?
It may be good to clarify how it works because it may affect the way people use Dynalist. Let’s say I use an offline laptop to add stuff to one of my files; can I use Dynalist on my phone on the same file and don’t be afraid of data loss when my laptop goes back online? Or is it better to avoid concurrent edits on the same file? Additionally, the concurrency model may affect the API shape.
Also I have some grip on the whole concurrent edits problem so I would be happy to help if any help is needed.
This is an issue if it’s like you say. I was doing stuff on my phone and I needed to move a whole bunch of stuff so i went over to a computer to do that move operation. If it’s like you say, i must wait for a full sync to server sync to phone before proceeding with edits, and if i don’t my changes will be lost.
Exactly. To be fair, concurrent edits are fiendishly difficult to get right, so it’s only to be expected that it will take some time for Dynalist team to sort them out. However, in the meantime it may be a nice thing to put into documentation and/or to discuss!
No, it’s last-writer-wins on a item (node) basis. If two client works on different nodes, there won’t be data losses.
If two clients make changes to the same node, the last client that syncs the data wins. We don’t attempt to merge the changes at the moment. So even if client A edits the very beginning of an item and client B edits the very end, the later one will rewrite the entire item.
I hope that helps.
If you work on the same items, the offline app will override those items, when it regains internet connectivity. So I recommend that if you use offline app, edit an isolated document rather than a volatile one.
Most of the data loss cases come from this case: the person writes a bunch of things on the offline app, and then made changes to the same items from a connected client.
Chronologically, he thinks the connected client should win, but when the previously offline client connects to the internet, the items that were edited by both clients gets what the offline app writes, not the connected client.
We don’t like this behavior, but it’s not straightforward to fix.
Here’s what’s written on our internal bug report, I’ll just copy and paste it here:
Title: Earlier changes on offline app overrides newer changes when offline client gets internet access
The most straightforward solution would be apply changes based on the timestamp when the edit was made.
But there are serious issues with this method. Let’s say client A is an offline client, and client B is an offline client. First, client A made changes on item X. After that, B made changes on the same item (X). When client A finally gets internet connection, it overrides item X after B’s changes.
The issues in this case are:
Right now, A overrides B. In the proposed solution, B overrides A, because the changes to X was first made in A and later made in B. The later one wins by the timestamp method. In both cases, one client loses data.
However, it’s possible for B to recover data with version history, since both changes from A and B has reached the server. It’s not possible for A to recover the lost data in the proposed solution though, since the changes to X from A never reached the server.
You may imagine it’s possible to put A’s changes to X before B’s changes on the server, before overriding it. But that involves inserting diffs at a random position in the version history, which is not part of our assumptions right now.
You say “a node”. So if I rename A, and elsewhere rename B, that’s no problem, right? Suppose I Move B and do some other edit? Suppose I move A, and separately edit B?
Just being sure. I feel like I have lost minor edits in the past, so understanding this will help me be confident what I can and cannot do.
