Optimistic Entity Framework Concurrency No Exception Occurs

Question

We have an ASP.Net MVC application that uses EF4 as the data access layer, and we see unexpected behavior regarding OptimisitCConcurrencyException exceptions that do not occur when we think they should be.

We simplified the problem to the following code ...

using System.Linq; using Project.Model; namespace OptimisticConcurrency { class Program { static void Main() { Contact firstContact = null; using (var firstEntities = new ProjectEntities()) { firstContact = (from c in firstEntities.Contacts where c.LastName == "smith" select c).Single(); } using (var secondEntities = new ProjectEntities()) { var secondContact = (from c in secondEntities.Contacts where c.LastName == "smith" select c).Single(); secondContact.Title = "a"; secondEntities.SaveChanges(); } firstContact.Title = "b"; using (var thirdEntities = new ProjectEntities()) { var thirdContact = (from c in thirdEntities.Contacts where c.LastName == "smith" select c).Single(); thirdContact.Title = firstContact.Title; //EXPLICITLY SET VERSION HERE thirdContact.Version = firstContact.Version; thirdEntities.SaveChanges(); } } } } 

This is a fairly simple version of what is happening in our MVC application, but the same problem occurs.

When we call SaveChanges on thirdEntities, I expect an exception and throws nothing.

Much more interesting, when we attach the SQL Profiler, we see that the version is used in the where clause, but the third Version Version value (current in the database) is used, and not the firstEntities DESPITE value, this is explicitly set immediately before the SaveChanges call. SaveChanges resets the Version as the received value, not the set value.

In EDMX, the version is set to StoreGeneratedPattern for calculation.

Does anyone know what is going on here?

Answer 1

This is problem. When a column is set to Computed , you cannot set its value in the application (you can, but this value is not used).

Edit:

If you load an object from a database, it is tracked by context by default. The context retains its original meaning. Source values, for example, are used to track snapshot changes, but they are also used as the only valid source of Computed properties. If you set the Computed property in your entity, the value is not used, and the original value is used by insted. The workaround is to change the original value (before you change anything else):

 using (var context = new TestEntities()) { var entityToUpdate = context.MyEntities.Single(e => e.Id == someId); entityToUpdate.Timestamp = entity.Timestamp; ObjectStateEntry entry = context.ObjectStateManager.GetObjectStateEntry(entityToUpdate); entry.ApplyOriginalValues(entityToUpdate); // set modified properties context.SaveChanges(); } 

Edit 2:

Btw. once you have loaded both the actual loaded timestamp and the previously obtained timestamp, you can simply compare them in your application and not do it in the database.