EF >= 4.1. Concurrency handling , logical row level check
I was hoping to get some feedback on the best way/ a good way, to handle logical row level optimistic locking in EF4.1 or higher on Table row changes.
I dont like the standard concurrency=fixed on fields, as this appears to allow concurrent change as long as the different fields are changed. If the integrity of the record required all fields to be considered as a set, what do people then do? set concurrency mode on all fields and also "update set them". What pattern emerges out of this issue?
Really what i want to do is have a field i use for concurrency, eg an Int32. If the it has been incremented in the mean time, then fail the update. Ie a field responsible for the concurrency not many fields. I used to do that manually. Each update checks conc=conc when changing the data it is setting and also has conc=conc+1.
Using EF do i just make this the concurrency field and mark it as FIXED and always update it as x=x+1, and EF does the rest.
What approach are the EF GURUs taking to address the row level concepts.
A few post have close but dont quiet address the question.
Or go in to alarming details on Defense in depth. Do every thing with views/sps etc.
I had hoped there was a simple pattern in EF that addressed the row level approach.
Row Level Security with Entity Framework http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/handling-concurrency-with-the-entity-framework-in-an-asp-net-mvc-application EF Concurrency Handling with Timestamp attribute in Model First approach
You simply create a special column in your table using timestamp or rowversion data type (these names are for SQL Server and may be different in other databases). This type does exactly the magic. If row is updated the value of the column changes. You only need to mark this column with ConcurrencyMode.Fixed.