Linq to SQL Data Concurrency - Is it safe to use only PKs?

Question

I am getting an error in my MVC-based website surrounding data concurrency in Linq to SQL:

"Row Not Found Or Changed"

After reading several posts on here it seems as though an accepted solution is to set all non-Primary key fields to UpdateCheck = false in the dbml designer. Before taking the plunge with this, I wanted to ask, will I be losing anything if I do this?

To be honest, it seems to me like this should always be the case, as using the primary key should be the fastest way to find a record anyway. This would be assuming that you don't have any composite PKs. I'm not terribly familiar with data concurrency scenarios, but am I missing something here?

Thanks for your time!

[EDIT]

Thanks for the feedback guys! To give some more detail, the specific scenario I have is this:

I have an Article table with a number of fields (title, content, author, etc.). One of the fields that gets updated very frequently (anytime anyone views the article), is a popularity field, which gets incremented with every click. I saw the original error mentioned above when I updated the article text in the database. Then navigated to that article on the live site (which attempted to update the popularity field).

For starters it sounds like I need to NOT be using a shared DataContext. Beyond that, maybe look into setting certain fields to UpdateCheck never. That being said, I definitely do not want the Article Popularity to not get update due to some concurrency issue. So with that being the case, is there a way for me to ensure this with optimistic concurrency?

Thanks again!!

Answer 1

I do sometimes change UpdateCheck to Never on all but the primary key(s) on entity classes in the designer myself. What you lose is notification of interim changes to the data since you loaded it; what you end up with is a "last change wins" type of scenario. If that is OK in your situation, then... fine.

There are situations where that is definitely not a good thing to do. For instance, checking/adjusting a bank account funds balance... or any situation where an alternation to a field is going to be based on a calculation with the current value as one of the operands.

Answer 2

set all non-Primary key fields to UpdateCheck = false in the dbml designer. Before taking the plunge with this, I wanted to ask, will I be losing anything if I do this?

The job of concurrency mechanisms is to prevent multiple users from stomping each others changes. Pessimistic concurrency achieves this by locking out changes to a record when it is read. Then unlocking the record when changes are complete. Optimistic concurrency achieves this by remembering what the record looked like when it was read, and then not modifying the record if it has changed.

Linq to Sql uses optimistic concurrency. If you set the UpdateCheck property that way, you are disabling optimistic concurrency checking.

Consider this record:

• Customer (Name = "Bob", Job = "Programmer", Salary = 35000.00)
• LinqToSql DataContext#1 reads the record
• LinqToSql DataContext#2 reads the record and commits the following change (Salary = 50000.00)
• LinqToSql DataContext#1 attempts to commit the following change (Job = "Janitor")

With optimistic concurrency, DataContext#1 now gets a concurrency exception to resolve. Without optimistic concurrency, we now have a janitor making 50k.