Objects are created and then modified by multiple threads. SubmitChanges() is called after every change, and is locked with a locking object to ensure that calls to all calls to SubmitChanges for the context are serialized.
In this scenario, how is it possible that I would get a ChangeConflictException when various threads modify a field that is marked "UpdateCheck = never"? I know I can handle the exception and implement "KeepChanges", but I don't know why I'm getting the exception in the first place. I would expect the last update to always overwrite without error if I set UpdateCheck = never on the field.
Turning to the documentation, it says:
Is this a typo? This states that ALL fields are marked to be checked (suggesting that the UpdateCheck is ignored). So I can't tell if I am misunderstanding concurrency handling because the documentation is ambiguous.LinqConnect uses the update check method to detect concurrency conflicts when submitting changes. All entity fields or part of them are marked for the check, and when updating an entity, not only entity key fields are checked, these fields are checked too.
One more piece of information that may be relevant:
The table in question has a one-to-many relationship based on the primary key of the main table. Updates to this linked table did take place concurrently with the main table updates, and the primary key is (of course) market UpdateCheck=Always. Could there be a bug in the cache management of the DataContext in which an update to the linked table is causing a "false positive" conflict on the main table?