The concurrency token would be the benchmark value used by EF to identify whether the transaction has a conflict or not. We will be exploring different types of concurrency tokens available and, if modified, how they stop the other user from updating the same.

The concept should be pretty simple, and we will keep ourselves in the shoes of the Microsoft developers and see what algorithm should be adopted for the implementation.

The following algorithm is required at the higher level:

• The entity should identify at least one column (concurrency check column) to let's validate whether the row is updated or not
• The identified column will be used in any update operation performed by the framework to check whether the update is valid or not:
  • The column is concluded as valid if the previous value in the updating model and the original value fed to the data store match, otherwise it would be marked as invalid
• If the concurrency column has invalid data then an exception should be thrown:
  • A new concurrency exception should be created that will allow users to handle them
  • We should give a provision to the user to handle concurrency issues, and that's the reason we should throw an exception instead of a graceful exit
• If the concurrency column has valid data, then the update could be performed

The algorithm could be visualized using the following flow chart:

Let's visualize the preceding algorithm to resolve the concurrency conflict we faced while updating the post:

• The Post entity identifies and configures the Timestamp column as a concurrency check column
• The concurrency implementation expects the Timestamp column to be valid:
  • The Post model, which we send to the framework to update, will have:
    • Current Timestamp value as a byte array
    • Original Timestamp value fetched from the database before presenting to the update screen
  • The Timestamp value's original value should match with the existing database value in the Timestamp value for the given row
  • If the value doesn't match, concurrency exception should be thrown
  • If the value matches, then the update is considered as valid and the framework allows the data store to be updated

We will explore the way in which the Microsoft team actually implemented the concurrency token mechanism:

• EF Core introduced a custom Timestamp attribute. Developers should mark one of the columns as the concurrency column
• The framework treats this column especially by marking the data loaded on the concurrency column in the context as the original value of the concurrency token
• When the user tries to update the record, it would check the original value against the value available in the database
• If the values don't match, then the framework throws a concurrency exception
• If both the values match, then the update is allowed by the framework

The concurrency token mechanism previously discussed matches with the flow diagram we used in this section. The concurrency is handled using the Timestamp property of the Post model, displayed as follows:

    public class Post
    {
      // Code removed for brevity
      [Timestamp]
      public string Timestamp { get; set; }
    }

We have exhaustively learnt about what is a concurrency conflict, how it could be handled, and how Microsoft has supported concurrency in EF Core. In the next section, we will learn how to configure and use them in applications.