I would like to understand how I can implement some form of record or field locking in my app, to prevent two simultaneous users of the same record overwriting changes, without the knowledge of the user.
I understand that cloud based databases, often suppress this type of functionality, because is a user forgets to log out, or becomes disconnected, the record could be blocked for an unacceptable period of time.
As the chances of locking are low, you would be looking at the classic “Optimisic Offline Lock” if you really want to prevent dirty writes.
So you either use the record updated timestamp, or some sort of version number when you do the update, and you check this before doing to update to make sure the version of the record you are updating is the one your first read.
You can have a field “locked_by” of type user that allows you to know which User is currently editing the object. You can combine this with Nigel’s suggestion: if the other user’s last change was longer than say 2h ago, you override the lock. Up to you to design the policy 
2 Likes
As george says it is up to you to design your own locking depending on your own requirements.
“Optimistic” locking (which isn’t really a lock at all) tends to be used when you have a small chance of two users accessing the same record, and it won’t be too bad if you then put a message up saying “Sorry, someone has already updated this”. This is what, for example, Amazon use for their account details update, open two browsers on the account page, change one and then change another, your get the “ooops, something changed” message.
“Pessimistic” locking (where you actually lock it) tends to be used in high concurrency situations, or when telling the user that after have spend 30 minutes entering data that it won’t work is not acceptable. However, this strategy comes with its own problems, particularly with people closing browsers and leaving locks.
3 Likes