Prevent Concurrency Conflicts

codemonkey21 commented 10 years ago

The reason I'm such a huge fan of checking for this is that most web applications have multiple users. Take your TaskEver example, a task could easily be updated by more than one user at the same time, thus creating the concurrency conflict.

"A concurrency conflict occurs when one user displays an entity's data in order to edit it, and then another user updates the same entity's data before the first user's change is written to the database. If you don't enable the detection of such conflicts, whoever updates the database last overwrites the other user's changes. In many applications, this risk is acceptable: if there are few users, or few updates, or if isn't really critical if some changes are overwritten, the cost of programming for concurrency might outweigh the benefit. In that case, you don't have to configure the application to handle concurrency conflicts."

Example of how this can be done. http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/handling-concurrency-with-the-entity-framework-in-an-asp-net-mvc-application

hikalkan commented 10 years ago

Hi,

I agree that concurrency conflicts is an important topic. Let me write my opinions:

First of all, there is no restriction in ABP to use the techniquies described in given link. You can do with EF whatever you can do with it without using ASP.NET Boilerplate.

The point is that: It's a little hard thing to implement concurrency as described in given link. Also, it requires similar works for all entity types. Can ASP.NET Boilerplate provide a common and easy way for that? Yes, it can :) Is it a feature of an application framework? Yes, I think. When? I don't know, we should plan it. How? We can discuss it here for different approaches. It may be like that:

We can define an interface (like IHasConcurrency) that defines a RowVersion property as like in the article. Then, rest is done by ABP like that:

While an IHasConcurrency entity is being updated/deleted, if EF throws a DbUpdateConcurrencyException then ABP handles it, rollbacks transaction and return an appropriate error message to the client.
In the client side, ABP handles these types of errors, shows it to the user and maybe allows a way of refreshing the entity in the screen.

What's your opinion?

codemonkey21 commented 10 years ago

I agree that this interface is the way to go. I was originally planning on creating my own interface for it, but wasn't sure if it would conflict with the deeper levels of ABP which is why I suggested it here. I like your suggestions.