Comments and changes to this ticket
Rather, my comment is that in most cases you can do without locking if you accept the result of the race condition.
If users u1 and u2 edit the same record, for the semantics of most applications it is fine that the last edit wins. Say for example we have this sequence:
- user u1 loads model m
- user u2 loads model m
- user u1 sends m modified
- user u2 sends m modified
Certainly u1 will see later that m does not have his changes, but in most cases this is no different than u2 editing a few seconds later from u1's point of view. Someone else changed it. If u2 decided m had to have that state, that's fine. Same for u1 if u2 submitted the changes first.
So rather than being the norm, for me is the exception. Perhaps you want to lock a wiki page, but I don't lock the edition of models in general.
Just to make myself clear. This comment was motivated by the introduction of the section of locking. It gave me the impression that is telling the user that if concurrency is possible in their app and they are not using some locking mechanism they are doing it wrong. And a series of locking mechanisms are mentioned in the last paragraph.
The introduction is right in emphasizing that you have to think about what it means in your application, and that you have to decide what to do about it. But I think it would be good to say that in some cases it is fine to do nothing, just accepting "last wins" semantics if they work for your application.