ChangeConflictException in Linq to Sql non-concurrent updates

Question

I'm using LINQ to SQL, and having a bit of an issue incrementing a view counter cross-connection.

The teeny bit of code I'm using is:

t = this.AppManager.ForumManager.GetThread(id);
t.Views = t.Views + 1;
this.AppManager.DB.SubmitChanges();

Now in my tests, I am running this multiple times, non-concurrently. There are a total of 4 copies of the object performing this test.

That is to say, there is no locking issue, or anything like that but there are 4 data contexts.

Now, I would expect this to work like this: fetch a row, modify a field, update the row. However, this is throwing a ChangeConflictException.

Why would the change be conflicted if none of the copies of this are running concurrently?

Is there a way to ignore change conflicts on a certain table?

EDIT: Found the answer:

You can set "UpdateCheck = Never" on all columns on a table to create a last-in-wins style of update. This is what the application was using before I ported it to LINQ, so that is what I will use for now.

EDIT2: While my fix above did indeed prevent the exception from being thrown, it did not fix the underlying issue:

Since I have more than one data context, there ends up being more than one cached copy of each object. Should I be recreating my data context with every page load?

I would rather instruct the data context to forget everything. Is this possible?

Answer 1

I believe DataContext is indented to be relatively lightweight and short-lived. IMO, you should not cache data loaded with a DataContext longer than necessary. When it's short lived, it remains relatively small because (as I understand it) the DataContext's memory usage is primarily associated with tracking the changes you make to objects managed by it (retrieved by it).

In the application I work on, we create the context, display data on the UI, wait for user updates and then update the data. However, that is necessary mainly because we want the update to be based on what the user is looking at (otherwise we could retrieve the data and update all at once when the user hits update). If your updates are relatively free-standing, I think it would be sensible to retrieve the row immediately before updating it.

You can also use System.Data.Linq.DataContext.Refresh() to re-sync already-retrieved data with data in the database to help with this problem.

To respond to your last comment about making the context forget everything, I don't think there's a way to do that, but I suspect that's because all there is to a context is the tracked changes (and the connection), and it's just as well that you create a new context (remember to dispose of the old one) because really you want to throw away everything that the context is.