Вот небольшой эксперимент, который я сделал:
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 не перезагружает мой объект, но повторно использует тот, который он ранее имел в памяти! Это проблема огромная для данных concurrency!
Как отключить скрытый кеш объектов, которые Linq явно хранит в памяти?
РЕДАКТИРОВАТЬ. При отражении просто немыслимо, что Microsoft могла оставить такую зияющую пропасть в рамках Linq. Вышеприведенный код - это тупиковая версия того, что я на самом деле делаю, и могут быть небольшие тонкости, которые я пропустил. Короче говоря, я был бы признателен, если бы вы сделали свое собственное экспериментирование, чтобы убедиться, что мои выводы выше правильны. Кроме того, должен существовать какой-то "секретный переключатель", который делает Linq устойчивым к одновременным обновлениям данных. Но что?