views:

112

answers:

2

I am trying to force a ChangeConflictException by altering records in two different browsers. This has worked for me in the past. But now it just wont throw the exception.

Last one in is winning.

I have checked the column properties of the entity I am updating and each column is set to always check.

Is there anything I can look for?

I haven't extended this data context or done any modifications to any of the properties.

Thanks.

Edit

This is an ASP.net application.

A: 

That's a race condition. Consider you are probably retrieving the info, updating and sending to the db. If the first commits the changes to the db, before the second retrieves the info you wouldn't get a conflict.

Update: About the comment on not being able to do it. You can do it, you use the Attach method but you need to keep any original values you want it to check for the concurrency. Check these:

linq2sql-update-object-not-created-in-datacontext

how-to-update-a-single-column-in-linq-without-loading-the-entire-row

That is surely what is happening under the linq datasource.

eglasius
I don't understand you. In seperate browsers: browser A gets a record and can edit it, browser B does the same. Both edit at same time. Browser A updates with success. Browser B then updates the same field and submits but overwrites browser A's changes. Shouldn't this be avoided by linq to sql?
Ronnie Overby
I do this exact same test in another app I wrote, it throws the exception just as expected.
Ronnie Overby
@Ronnie veggerby explained it well :)
eglasius
+2  A: 

Are you sure this is not what is happening:

  1. Browser A loads entity X
  2. Browser B loads entity X
  3. Browser A submits form
  4. Browser A loads entity X again, changes property and stores again
  5. Browser B submits form
  6. Browser B loads entity X again, changes property and stores again

Key point here is that the entity is reloaded on postback (HTTP = stateless) and in 6) you are actually loading changes made by 4) and overwriting them. Linq2Sql does not "stamp" your form you would have to do this manually.

You write in the comments that you have another app that works. If that is a Windows app, then the situation is completely different, since the entity is then most likely not reloaded again.

veggerby
They are both ASP.net apps.
Ronnie Overby
The other app is using LinqDataSource. The update is manually coded in this one. How can I keep the entity across post backs? I think L2S will complain about the entity being from another datacontext.
Ronnie Overby
You probably can't and shouldn't. You would probably need a Row GUID, timestamp or other versioning column that you put in a hidden field in the form and verify this at postback. Admittedly I don't know if there is anything native in L2S that does/helps with this.
veggerby
+1 exactly.@veggerby you can, check my update. It can be combined with what you say on guid/timestamp, to avoid keeping extra info.
eglasius