0
votes

How does Entity Framework 6 handle optimistic concurrency of a one-to-many relationship in an ASP.NET MVC app? I'm having trouble determining what EF should be able to handle itself vs. what I have to handle manually. Just about every article I find on EF concurrency checking in a web app only handles the simple case where a RowVersion column or a Timestamp column is used as a concurrency field; they don't seem to mention relationship concurrency checking.

I'll be brief with the following explanation, since I assume this is nothing new to people who can answer this question. Since this is a web app, I dispose of the Entity Framework state on every round trip from the server. In the simple case of updating a column on a table, I have to save field values that are used for optimistic concurrency (such as RowVersion) onto the HTML page, and then post them back to the server when the page is submitted. When the page is submitted, I retrieve the current database record using EF, update it with the concurrency values from the HTML page, set the state of the EF DbEntityEntry object to EntityState.Unchanged, and then set the other values from the page to the EF record. EF can then do its own concurrency checking when SaveChanges() is called. So, how should a one-to-many relationship work in relation to this pattern?

Here's a concrete (though contrived) example. Assume I've got a model of one Album to many Songs. User1 and User2 both start modifying the same Album concurrently by updating Songs. User1 adds a Song, and User2 removes a Song. What should I do to get EF to automatically detect that User1 has added a song before User2 has deleted one (or vice versa)? Or will I manually have to detect that the list of Songs has changed? One possible way is to do something like update a SongModifiedVersion column on Album when a Song is added or deleted, and have EF use SongModifiedVersion as a concurrency field similar to the suggestion in Entity Framework Concurrency with Multiple Tables/Entities). Is there another way?

Thanks, Bill

1
What DB are you using?Pedro
Pedro - Oracle 12c. Sorry for not listing it in the post. I didn't think it would matter from an EF perspective.Bill at Work
The reason I asked is because I usually rely on the DB builtin transaction support and isolation level to handle concurrency instead of doing it by hand (or in EF).Pedro

1 Answers

0
votes

I usually rely on my DB transaction and isolation level support to handle concurrency, not do it by hand. In this case, I'd check what Isolation Level from your DB best fit your business concurrency needs/model.

I also never manually change EntityState directly myself and rely on EF to track changes.