Вот небольшой эксперимент, который я сделал:

MyClass obj = dataContext.GetTable<MyClass>().Where(x => x.ID = 1).Single();
Console.WriteLine(obj.MyProperty); // output = "initial"
Console.WriteLine("Waiting..."); // put a breakpoint after this line
obj = null;
obj = dataContext.GetTable<MyClass>().Where(x => x.ID = 1).Single(); // same as before, but reloaded
Console.WriteLine(obj.MyProperty); // output still = "initial"
obj.MyOtherProperty = "foo";
dataContext.SubmitChanges(); // throws concurrency exception

Когда я достигаю точки останова после строки 3, я захожу в окно SQL-запроса и вручную изменяю значение на «обновленный». Затем я продолжаю бежать. Linq не перезагружает мой объект, но повторно использует тот, который был ранее в памяти! Этоогромный проблема для параллелизма данных!

Как отключить этот скрытый кеш объектов, который Linq явно хранит в памяти?

РЕДАКТИРОВАТЬ - Если подумать, то просто немыслимо, что Microsoft могла оставить такую зияющую пропасть в среде Linq. Приведенный выше код представляет собой дурацкую версию того, что я на самом деле делаю, и, возможно, я пропустил некоторые тонкости. Короче говоря, я был бы признателен, если бы вы провели свои собственные эксперименты, чтобы убедиться, что мои выводы выше верны. Альтернативно, должен быть какой-то «секретный переключатель», который делает Linq устойчивым к одновременным обновлениям данных. Но что?