The Entity Framework (EF) approach to concurrency is to mark one or more fields as ‘ConcurrencyMode=Fixed’. This can be done either directly in the edmx file or via the Entity Data Model Designer. The EF will then use the original value of the field as a condition on any update. If the value has changed the update will fail and a concurrency exception will be thrown.
This works well for a long running context and so we been happy to use it for thick-client implementations of Naked Objects. However the MVC implementation uses a context that only survives for the duration of the web transaction. The EF concurrency check will then only check for changes during that transaction – this is of some value but it doesn’t catch the situation where an object is opened for edit (in one transaction) changes are made and then submitted (in another transaction).
As a slight aside here we need to be aware of how Naked Objects MVC handles the persistence of an object from one transaction to the next. Naked Objects passes an identity token (in the URL) which is then used to repopulate objects from the data store. These are then used to make any changes or run any actions and then save changes to the store. This has the advantages that it is completely stateless – everything is in the Http Request – and cleanly decoupled from the object store implementation. It does though have the disadvantage of an additional object store query.
With EF an alternative would be to serialize all or some of the object state, recreate the entity and attach to the context. This is an option for the future but there’s quite a few hoops to jump through to get this working, especially in an object store independent way and within the constraints of the existing Naked Objects architecture. So for the moment simplicity and object store independence win the day.
So back to concurrency, it seems to be possible to set the token in the object and tell EF to accept it. Then when other changes are applied and the object saved the standard EF concurrency checking should kick in. This is obviously a good solution in that it’s a common concurrency mechanism across thick-client and MVC Naked Objects implementations. This would be easiest if we had adopted the reattaching EF mechanism but should be possible with our current object retrieval mechanism. However it once again means coupling ourselves to EF or building a lot of EF specific stuff into our generic object store API.
Finally then the simple approach we adopted is to save the concurrency token as a hidden field on object edits and views. For edit sessions the original value survives the length of the edit (which may involve intermediate posts). Then when the edited object is saved or an action is invoked we check against the current database value (which we’ve populated in the object anyway) and fail concurrency if it’s changed. This is simple, obvious what’s going on if you want to customize the application and fits in cleanly with our existing architecture. The only disadvantage is that we need a way of identifying the concurrency token fortunately Microsoft have provided a new attribute – ConcurrencyCheckAttribute – which we use. As this is also used in EF Code First to mark those properties that are “ConcurrencyMode=Fixed” this is all that is necessary for Code First development. For Model and Database first the same fields marked “ConcurrencyMode=Fixed” should also be annotated ‘ConcurrencyCheckRequired’.