OK, I was writing the state at the end of the method, once everything was really done. In case some action does not change the state of my main object (e.g. partial processing of the stock moves), then I'll have no other choice but lock, correct?

Actually, writing the state at the end of the method should work too, as long as it is done in a single transaction. The key part is the "read state" + "write state" sequence of operations that the database should detect as a serialization conflict ("one transaction looked at the state, then updated it, while another one was doing the same thing...obviously one of them should have seen what the other had done first.") As for partial processing, you should perhaps consider having a state on each "entitlement" and use the same mechanism. If you partially process data without maintaining any intermediary state and write the result on unrelated records (new stock moves) then indeed the system would have a hard time detecting anything as a "duplicate" operation, and you would need custom protections such as explicit locking.

You are totally right. After further analysis, it turned out that the server-side code had no check for the current state and would only write the new state, relying on the client-side visibility of the button to prevent the actions from being triggered in the wrong state, which is obviously a very bad idea.