uwazi
uwazi copied to clipboard
huridocs
Implement locking strategy to avoid concurrence conflict
While the probability of concurrence conflicts in Uwazi is still relatively low, some users have started to experience this problem when ie. working on the same thesauri from different sessions at the same time.
An locking strategy is starting to be necessary, I think Optimistic Offline Lock is the rights approach of Uwazi ofr most use cases.
Related: https://github.com/huridocs/uwazi/issues/2123
@txau, transaction support is available on mongo 4.0 we should consider migrating and check how difficult will be for us to use the new transactions api with in Uwazi.
@daneryl makes sense, although rather than rollback what we need is conflict detetion
@txau our action normally span multiple db operations, that is why i think we can not just detect a conflict and stop, will produce inconsistencies on the data if the detection does not occur in the first query, that is why Optimistic offline lock needs transactions to work properly i think, @RafaPolit ?
Maybe it could also help to reduce the granularity of update operations.
At the moment, whether you add new items to the thesaurus, delete items, rename a few items, the entire thesaurus body is sent to the server as a single save operation.
Maybe it would help to have a separate operations for adding items, deleting items, editing an item, etc. That way if one user is adding items, and another user is deleting or updating items, the two operations could take place concurrently without affecting each other.
If a two users are renaming the same item, then regardless of approach, only one of the updates would end up taking effect at the end. I think there is a problem when one user is performing a delete and the other is performing an update of the same item. In this case, I think the atomic findAndModify operations would be useful to ensure that the update succeeds only if the item already existed, i.e. occurred before the delete operation.
I think this approach would allow use to considerably reduce chances of collisions without requiring transactions, and would probably provide better performance.
@habbes good point. I guess that works for thesauri. But in the cases of entities, we still need to send all the metadata, isn't it?
@txau mongodb supports updating nested fields without having to send all the data, in case of entities for metadata can be done also but, specific query needs to be created for this instead of just sending the data, the initial idea was to avoid this as it adds more complexity to the whole process of saving.