The management of concurrency in web applications is one of the issues to which we should devote a little quality time, since due to the nature of the application we may find cases in which several users have to interact with the same item.
By itself this interaction is not a problem, the real problem comes when after having modified or touched this element it is necessary to save in database and then two or more users want to take action on the same element at the same time, there it is where our logic must define a behavior to know what is the appropriate way to handle this.
Concurrence in Databases
As we explained at the beginning, the concurrence is when two or more actors work on an element in our application generating an action against the database.
Concurrence case
Problems can occur when the changes are conflicting, for example: user A saved a value, but user B was at that time also modifying and saved a different value, in the eyes of the user. Its content was not modified and in the eyes of the user. B there was nothing that prevented him from making his change.
This type of conflict can tarnish the performance of our application in the eyes of the user, so we must assess whether the areas that are available will be worthwhile or not scheduled for concurrency.
Types of Concurrence
Let's look at some types of concurrency, in this way we can understand a little more what kind of actions we can execute in our applications:
Pessimistic concurrence
This approach suggests that when using the database, we prevent the registry in use from being blocked, thereby preventing multiple users from changing the value simultaneously, the problem results in the fact that in the web environment it is not possible to use it thoroughly, since Since there are no states, we do not really know if the block was applied or removed until we communicated with the server, generating confusion and slow use.
Optimistic concurrence
This other approach, on the other hand, does something a little more compatible with the web, when modifying, before saving in the database, verify that the data has not been modified from the moment the reading was made, for this we make comparison of registry values and an associated field that has a temporary fingerprint with date, time and seconds for greater accuracy.
How does ASP.NET MVC solve it?
ASP.NET MVC does not support the pessimistic approach, so we must work with the optimist, for this we must provide our structures with date fields to save the last time it was modified, so we can know if the value was changed later that we obtained the record and before saving it, with it we can obtain an alert and thus decide whether or not to overwrite those values.
Let's look at a small code example of how we could validate this:
We note then that we validate when making a change in the database if the field was modified after we did the reading, if so we raise an exception, with this we can already take the corresponding actions, we also leave space to work the different exceptions that can be generated.
Finishing this tutorial we already know a little more about concurrency in databases and how to work the problem in ASP.NET MVC .
Articles