Repository navigation
Replies: 1 comment 1 reply
|
My comment on concurrent modifications via the REST endpoints: The REST APIs of the admin UI are of a "last write wins" pattern, which is not a good concurrency strategy, as user might see information in the UI, submit them, and they might overwrite something that another user has modified/added to the database in the meantime. Adding pessimistic locking doesn't improve this; it might prevent an exception in the code, still the last-write-wins pattern applies, which not much good for the caller. At the same time the modification pattern is that one user modifies their own data, and that shouldn't be done concurrently, but page after page. This is different from for example a login scenario where multiple tabs are restored at the same time, and we need to handle concurrency for a single user. So I argue it is OK to throw an exception here if a concurrent modification is happening. On the formation of the notification: I'd first like to see what the current behavior is, and review it, before coming up with something custom. For now, any 5xx error code (server error as "something bad happend on the server") would do as well as a 4xx code (client error - "the caller shouldn't do something concurrently") as long it is somehow consistent with how we handle such an exception in other places. |
|
So if I understand correctly, your proposal is to have optimistic locking everywhere, but have the possibility to read with pessimistic locking in cases when needed like the user sessions scenario you mentioned, where one user can concurrently modify their user session from more tabs? This means each storage should support both locking strategies. From my point of view, we should aim for getting rid of the last-write-wins pattern. Should we plan some refactoring of all the places where we need pessimistic locking and try to replace it with optimistic locking somehow? |
Uh oh!
There was an error while loading. Please reload this page.
I'd like to discuss how we should handle concurrent modification of the same object from user/admin perspective.
Should we ensure that we guard concurrent modifications in all implementation?
Should we then propagate the exception to the user?
What format would have the notification?
All reactions