Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The user will care about the message, because he wanted to do some modification, and the modifications have not been made. He will thus refresh the page to see the new state of the data, and will redo his modifications, or decide they should not be made anymore given the new state.</p> <p>Is it a problem if two users modify an entity concurrently, and if the last modification wins, whatever the modification is? If it is a problem, then use optimistic locking, and inform your user when there is a problem. There's no way around it. </p> <p>If it's not a problem, then don't use optimistic locking. The last modification, if it doesn't break constraints in your database, will always win. But having concurrent users modifying the same data will <strong>always</strong> lead to exceptions (for example, because some user might delete an entity before some other user submits a modification to the same entity).</p> <p>Retrying is not an option:</p> <ul> <li>either it will fail again, because it's just not possible to do the modifications</li> <li>or it will succeed, but will defeat the point of having optimistic locking in the first place.</li> </ul> <p>Your problem could be explained with a car analogy. Suppose you choose to buy a car with a speed limiter, in order to make sure you don't break the speed limit. And now you ask: but I don't care about the speed limits. Shouldn't I always disable the speed limiter? You can, but then don't be surprised if you get caught by the police.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload