-1

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.

Improve this question
3
  • I think you should ask the person who asks for this feature how, from a business perspective, the new torpedo feature should interact with the exclusive access (provided by the locking) and then use that business explanation as input for your software design. – Bart van Ingen Schenau Jun 5 '20 at 9:36
  • The most straightforward option is to require users to take a exclusive lock on all the lists they may affect, before updating any of them - so if the user intends to "torpedo" other lists, he must hold a lock on those lists too. In your case, the operation would not proceed at all until user A seized the lock on list 2. As to how he gets the lock from user B, there should be some means of human communication between users to resolve conflict (including, in the end, the ability to seize locks unilaterally from unresponsive users). – Steve Jun 5 '20 at 10:18
  • Thanks for your comments. I agree, exclusive access makes sense (though it's not entirely what business wants, well what they don't want is for this operation to fail for this reason). I'm guessing this will need more discussion for now. – user642770 Jun 9 '20 at 16:51
0

Layers

What is a list? It is meta data about how a set of items are organised with respect to one another.

What is an item? A Nexus of related attributes.

This problem is in fact two problems:

  • How do you manage updates to a List.
  • How do you manage updates to an Item.

Updating A List

Looks like you have this under control.

Updating An Item

It looks like you are aiming for an optimistic lock, A.K.A. First in Best dressed.

Everyone can edit the item locally, when they go to save it the first person through is accepted, everyone else gets a polite "It has already been updated, try again".

You can dress that last part up with some extra information, such as what changed, perhaps an auto-merge.

Improve this answer
4
  • Actually a list update could mean completely replacing an item with another new item. And that scenario when mixed with the "torpedo" to other lists is what i'm asking about – user642770 Jun 5 '20 at 8:40
  • Then that is just a replacement of the item. Ergo Update the item. – Kain0_0 Jun 5 '20 at 8:45
  • We can't update the item. WE need to replace it with the other item in that list so the list has now changed – user642770 Jun 5 '20 at 9:00
  • @user642770 Why not? If the issue is historical accuracy, then implement a revision control on the item. the Item is updated, by inserting a new row (not by modifying the previous data). If it is a search/replace functionality why not model it as that. User A submits a Search and Replace task, which is applied to each list as appropriate. Do not guarantee immediate application, instead opt for best effort and failure communication. – Kain0_0 Jun 6 '20 at 11:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.