Linq to SQL - Грязные чтения после обновления - Служба WCF

Question

У меня есть файл dbml (linq to sql) для подключения к моей базе данных. У меня есть менеджер, который использует общий репозиторий (для каждой сущности) для общения с базой данных. Менеджер использует Репо для выполнения работы (операции CRUD). WCF оборачивает менеджера и предоставляет его внешнему миру (чтобы мое приложение могло его использовать).

БД <-> IRepository <-> IManager (IRepo, IRepo ...) <-> WCFService (IManager)

Я проверил менеджер, он работает каждый раз нормально. Проблема в WCF. Я прочитаю данные (например, GetAllLocations), обновлю данные (например, изменю имя местоположения), но потом, в какой-то случайный момент позже, прочитаю грязные данные. Например. если я менял имя местоположения с «BC 1», на «BC 2», на «BC 3», иногда я его читаю и получаю более старые значения. Как после того, как я изменил его на «BC 3», и я ожидаю прочитать «BC 3», я получу «BC 1» (что в любом случае не имеет смысла, так как значение до обновления было «BC 2»). WCF не имеет кэширования по умолчанию, так почему это происходит на моем WCF, а НЕ на моем менеджере? Все, что делает WCF - это передает значения менеджеру и получает значения от менеджера, это очень простой класс-оболочка.

ПРИМЕЧАНИЕ. Я использую StructureMap для автоматического разрешения вещей DependencyInjection и IoC.

Методы проблемы: все, что читает (например, GetLocationById и GetAllLocations). Они просто не всегда возвращают последние данные из базы данных. Я знаю, что это не менеджер, потому что я создал простой проект для независимого тестирования менеджера и WCF, и только WCF имел грязные чтения после обновления данных (в частности, расположение). Я еще не тестировал все остальные объекты.

Последнее замечание: я продолжал получать «System.Data.Linq.ChangeConflictException: строка не найдена или изменена». исключение. Я изменил свойства объекта Entity для определения местоположения DBML (кроме PK) на Update Update: Never. Грязные чтения происходили до этого изменения в любом случае, и менеджер работает нормально (и он использует DBML). Поэтому у меня нет оснований полагать, что это вызывает грязное чтение.

Кроме того, у Entity Location есть триггер в базе данных, но я исключил это как причину, потому что отключил его, и это не помогло, и снова, менеджер работает нормально.

Answer 1

Оказывается, это была проблема с кэшированием, вызванная использованием WCF и Структурной карты. Я изменил кэширование структурной карты по умолчанию при регистрации моих контекстов данных в реестре данных.

For<MyDataContext>()
   //.HybridHttpOrThreadLocalScoped()
   .Use(() => new MyDataContext());

По умолчанию для каждого звонка было то, что мне было нужно.

Answer 2

Существует несколько причин, которые могут вызывать это:

• Изоляционный уровень области действия внешней транзакции может быть другим
• Одно отличие от WCF состоит в том, чточерез IIS может привести к одновременному запуску вещей

Можно попробовать:

• Установить уровень изоляции области транзакции
• убедитесь, чточто ваша строка подключения включает MARS - несколько активных результирующих наборов