I needed some design suggestions for a tricky workflow we have to implement in our system:
At a basic level the application allows users to work on a "list" of "items" she cares about
To work on any list the user "locks" the list and can edit/save/unlock etc. No one else can open the same list in the UI for editing, while it's locked.
The new scenario that I need to design goes something lie
BUT Now we need to implement a feature where another user could indirectly update a list locked by someone else with common items with the list she is updating
This operation will allow any user who has locked a list, to make certain updates to an item in that list which it can "torpedo" to every list that contains that item (even if they are locked by another user). That item has to be updated across the board and all other users should see this update on the screens if they are editing a list containing that item.
So my design was going to be:
User-A locks list-1 and decides to "torpedo" a change which also affects list-2, list-3
Assume list-2 is currently locked by User-B but no one is working on list-3
The task processing list-1 tries to also lock list-2 and list-3
It succeeds in locking list-3 and does the update (This part is easy)
Question is: How does it handle list-2 which is locked by User-B?
- It could sent out a message with the list-id and the task processing it could pick it up and queue for processing BUT while the message is in delivery the list-2 processing could be complete and that task does not care about it anymore?
I'm really struggling to come up with a good solution here that does not introduce tons of race-conditions.