As the name suggests, we perform locks at the data store that prevent users from updating stale data at the cost of performance. Yes, managing those locks by a data store consumes more resources, which in turn affects the performance. This could be achieved in the following way:

• While reading/updating the data from/into the data store, we will request a lock for other read-only or update access:
  • Locking a row for read-only access will allow other users to gain a lock for read-only but not for update
  • Locking a row for an update access will not let any other users either lock for read-only or update

Pessimistic concurrency could be adopted in the application where the users were too specific with the data and they do not compromise how the data was dealt with against the performance. The persisted data will always be valid, or in other words, we might never run into conflicts, but with a huge cost, performance. Every persistence will involve an overhead that ensures that we never run into conflicts with data persistence. In most scenarios, we will never compromise performance, and taking this approach would be very rare.

The ASP.NET Core Microsoft documentation (https://docs.microsoft.com/en-us/aspnet/core/data/ef-mvc/concurrency) highlights the disadvantages of pessimistic concurrency:

"Managing locks has disadvantages. It can be complex to program. It requires significant database management resources, and it can cause performance problems as the number of users of an application increases. For these reasons, not all database management systems support pessimistic concurrency. Entity Framework Core provides no built-in support for it, and this tutorial doesn't show you how to implement it."

Even though EF Core does not support pessimistic lock, we could leverage the same using flat SQL queries. We have learnt about pessimistic concurrency in this section; let's move on to start applying these concurrency tokens in the next section.