2 Different users updating the same web application page in different places RRS feed

  • Question

  • I have a web application with 2 users registered.

    User1 opened the web application in UK and updated the Category Type in Category Details, at the same time User2 opened the same web application in INDIA and updated Category Name in Category Details. User1 updation will be overwritten by User2 how can I achieve this scenario with Entity framework and other as well.

    Can you pls help me...

    Thursday, May 9, 2013 4:32 AM

All replies

  • You want to look into optimistic concurrency.

    Google it.

    Here's an article:


    Essentially, you add a timestamp column to all your tables.

    When EF comes to update it checks that the timestamp of the record it's about to change is the same as the data it read.

    You trap the error if it's generated and tell the second user the data has been updated by someone else.

    Thursday, May 9, 2013 11:14 AM
  • Hi Kapil,

    You can achieve the same by handling Concurrency in EF. You have to choose any one of the concurrency types described below:

    ü  Pessimistic concurrency – This is achieved by the use of database locks.

    For ex, before you read a row from database, you request a lock for read-only or update access. If you lock a row for update access, no other users are allowed to lock the row either for read-only or update access, because they would get a copy of data that's in the process of being changed. If you lock a row for read-only access, others can also lock it for read-only access but not for update.

    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. The Entity Framework provides no built-in support for it

    ü  Optimistic Concurrency – This is the alternative to pessimistic concurrency Optimistic concurrency means allowing concurrency conflicts to happen, and then reacting appropriately if they do.

    In the 1<sup>st</sup> approach of optimistic concurrency, you can keep track of which property a user has modified and update only the corresponding columns in the database. This method of updating can't avoid data loss if competing changes are made to the same property of an entity. The way Entity Framework works depends on how you implement your update code.

    In 2<sup>nd</sup> approach, you can let the last person’s change overwrite the previous changes. The next time someone browses, they'll see the last scenario updated. This is called a Client Wins or Last in Wins scenario.

    In 3<sup>rd</sup> approach, you can prevent last person from being updated in the database. Typically, an error message is displayed, showing the current state of the data, and allowing the user to re-apply the changes if needed. This is called a Store Wins scenario. (The data-store values take precedence over the values submitted by the client.) This method ensures that no changes are overwritten without a user being alerted to what's happening.

    Detecting Concurrency Conflicts – You can resolve conflicts by handling OptimisticConcurrencyException exceptions that the Entity Framework throws. In order to know when to throw these exceptions, the Entity Framework must be able to detect conflicts. Therefore, you must configure the database and the data model appropriately. Some options for enabling conflict detection include the following:

    • In the database table, include a tracking column that can be used to determine when a row has been changed. You can then configure the Entity Framework to include that column in the Where clause of SQL Update or Delete commands.

    The data type of the tracking column is typically timestamp, but it doesn't actually contain a date or time value. Instead, the value is a sequential number that's incremented each time the row is updated. (Therefore the same type can be called rowversion in recent versions of SQL Server.)

    In an Update or Delete command, the Where clause includes the original value of the tracking column. If the row being updated has been changed by another user, the value in that column is different than the original value, so the Update or Delete statement can't find the row to update because of the Where clause. When the Entity Framework finds that no rows have been updated by the Update or Delete command (that is, when the number of affected rows is zero), it interprets that as a concurrency conflict.

    • Configure the Entity Framework to include the original values of every column of the table in the Where clause of Update and Delete commands.

    As in the first option, if anything in the row has changed since the row was first read, the Where clause won't return a row to update, which the Entity Framework interprets as a concurrency conflict. This method is as effective as using a tracking column. However, for database tables that have many columns, this approach can result in very large Where clauses, and can require that you maintain large amounts of state. As noted earlier, maintaining large amounts of state can affect application performance because it either requires server resources or must be included in the web page itself. Therefore this approach generally not recommended.

    Thanks, AT

    Thursday, May 9, 2013 1:20 PM
  • Pessimistic concurrency isn't suitable for a web application.

    A user can just close a web page and you're left with a lock - forever.

    Thursday, May 9, 2013 2:27 PM
  • Pessimistic is only one of the mentioned options. I have talked about optimistic concurrency in the next para.

    Also mentioned, "The Entity Framework provides no built-in support for it (Pessimistic concurrency)". Since EF does not provides support, we are left with only one choice: Optimistic.

    3 approaches to implement Optimistic are also mentioned in the reply.

    Thanks, AT

    Thursday, May 9, 2013 2:36 PM
  • I agree with Andy. But for an alternative you may want to consider a more relaxed approach. The two 'conflicting' requests could be queued and both users are told their requests are pending...or if the likelihood of a clash is small perhaps just assume they'll work and notify them of a problem later - super optimistic. This type of approach can be well suited to non-time critical but high volume web sites. You can see it occur in real life. I recently bought an ebook from Amazon and it was delivered to my Kindle. However, my card details were incorrect but they'd already delivered the book. They've taken the view that the risk to ROI of a more complicated solution is worth it. They then send a nice email to attempt to 'compensate' for the problem. My point is to look at the problem domain rather than try and force it into a technical solution.


    • Edited by pkr2000 Wednesday, May 15, 2013 10:11 PM
    Wednesday, May 15, 2013 10:10 PM