We need to visualize where we would be facing this issue, in general, when the user tries to update data that is stale, which means the underlying data in the database has changed since the object was filled. Then we have a problem that needs to be addressed before we go live. If we don't handle concurrency, then the user who updates it last would retain his change, overwriting the data updated by other users.

In a real-world application, no single user accesses the application at a single point in time, multiple users use the application and it complicates the persistence of the data store.

Let's look at some scenarios that occur in such an application:

• Two users try to update the same entity at the same time
• If one of the users succeeds in the first persistence, then we end up overwriting the same entity by the second user

This is our point of interest, which could be coined as concurrency conflict. To replicate the issue, open the Edit Post page in two tabs. Assume the first user in the first tab is updating the post information, such as editing a blog post's Title and Content:

Another user in the second tab tries to modify the Post Content, who is unaware of the change performed in the Post Title and content by the other user (from the first tab):

The change committed by the first user is no longer available in the model, which overwrites the data from the second user. Further execution with the highlighted data in the below screenshot would overwrite the data from second user:

The Post list displays that the changes performed by the first user are overwritten by the second user:

The change committed by the first user should not be removed/overwritten with the new data without considering the data updated in the database. This is a concurrency issue that we will be discussing further in the next section.