Conquering concurrency one at a time
In this short article I will not be touching any asynchronous code or concepts. It will also be not about eventual consistency.
There are specific situations when we may have problems with the other type of concurrency, and the biggest problem is discovering the possibility that the system allows for data to be overwritten without end user’s intentions.
The solution is easy.
Factory case
Imagine a system in which we are making orders to the warehouses for specific products or parts.
If the orders can be saved as a draft and edited by multiple users, that would be the first vulnerability. Two users can edit the same order at the same time!
-But c’mon, would they edit one order that long time to have a concurrency problem? I buy stuff online in less than a minute…
It depends on the system. For a very complicated order that has many dependencies with the chosen options (imagine a car, computer hardware or even made-to-measure suit), making partial order will not be possible.
When it is possible to choose from more than 200 fields and to understand them during making the order (having a coworker explain something or referring to the documentation), it can take a very long time to fill that order.
Single user?
What if only one user is allowed to do edit operations?
We should not be relieved. That one user can open a new instance of our application (for a web application, open it in a new tab or new browser same time) if we do not disable that possibility deliberately.
More, the user can use virtual machines to work with our software and make a snapshot in the middle of editing an order.
If our session handling timer is based on in-memory data, it will not be possible to discover that the session has ended. The system clock on that client VM is something we can try to rely on, but we will not be 100% sure.
Strategies
Issues like described above can be solved by two approaches.
The pessimistic approach would be to lock the editing of a certain element to one user and/or session. Any other user or the same user accessing the element from another browser would be in a read-only mode.
A drawback of that solution is a session handling – when the original session crashes, the inactivity timeout must be worn off before the element will be editable again.
The optimistic approach may try to:
-merge changes
-inform the user that someone else is editing the document
-highlight fields that have changed in the meantime
-allow overwriting the data e.g. for high privilege accounts
-have a history of changes (field, value, user, date) saved
The validation needs to be done on the data level (server/DB), as clients do not have the latest updated version of the data.
Happy ending
For the order form described in the beginning, there could be a conflict view that will highlight fields and show data currently in the database, as well as fields entered by that user.
That way the user does not have to save his changes somehow (copy to notepad? make a photo of a screen?), then reload order, and then make his changes again (hoping nobody else edits the form in the same time!).
Related articles
Optimistic Concurrency vs Pessimistic Concurrency – short comparison by agirlamonggeeks
Optimistic and pessimistic concurrency control by iryndin.net
Leave a comment