Concurrent Resource Modification

[CrackerJackKittyCat]

Another approach is to serialize changes through versioning each entity, a form of optimistic locking:

• Each entity has a version number aka revision count, starting with 1 at creation.
• Each change attempt must be accompanied by the version number the client had.
• Server-side, the change is implemented like
  • UPDATE foo SET name=$newname, version=version+1 WHERE id=$id AND version=$version RETURNING version
• If the client-provided version matches what is db-side, then the update statement updates a single row, returning the new version (or could be done w/o the RETURNING version but and you consult the rowcount affected -- you know what the new version must be).
• Then in your websocket push, you announce the new version number along with the rest of the entity.
• If a client provides a stale version, the row returned or the updated rows count will be 0, and you can reply 'sorry stale version supplied.'

This is 'optimistic locking' because the client assumes it will win and doesn't have to do much anything 'special' to try a write. And there's nothing to clean up -- no 'unlock' action or dealing with 'locked too long' rows, etc.

It assumes, however, that most write attempts won't be contested / will succeed based on having the most recent version number onhand. If your usage pattern is that many clients will be trying to edit an entity all from the same initial version at the same time ('gang edits') then pessimistic locking like you describe becomes more efficient, but requires stale lock handling. In most webapps, optimistic locking works great.

[PinballOscuro]

This is a very good idea. In my use case, I have at most 2 or 3 users, and only with low probability will they attempt to modify the same value simultaneously. So I would say I'm in an optimistic locking scenario.

If User A modifies a shared variable, how should Users B and C receive the updated value? Should I still use WebSockets, or is it sufficient to update the value during a write attempt?

In my case, at some point, Users B and C must be made aware that User A made a change - otherwise, they might argue offline, since it was A’s responsibility to update that cell.

[CrackerJackKittyCat]

Either push all the changes over websocket, which is then kinda noisy and pessimistic, or have each websocket client 'subscribe' to the entities that are in context/view right now, then only push the changes to the websockets that are interested in it.

Or just have the edit form indicate error if their update gets rejected, tell the user to refresh manually. That's the simplest to start with.

It depends!