Соображения параллелизма с Entity Framework - PullRequest
0 голосов
/ 06 февраля 2020

Настройка

Использование Visual Studio. NET и C#. Я создаю веб-приложение, которое имеет 2 различные цели:

  1. Веб-приложение с кварцевым заданием, которое подключается к внешней системе для получения данных и хранения данных в SQL Сервер. Это делается каждые 5 минут. Некоторые данные изменяются или рассчитываются до их сохранения. Я использую Entity Framework с подходом «сначала код».

  2. Другая цель - это REST Web API, который дает другим системам доступ к данным, которые находятся в базе данных. Данные, которые собираются веб-приложением, упомянутым выше.

В веб-приложении и веб-API используются одни и те же модели, поскольку они оба являются частью одного и того же проекта. У меня есть один класс, который наследуется от DbContext, который они оба используют для получения доступа к данным.

Теперь мой вопрос.

Боюсь, что получу проблемы параллелизма. Если кто-то использует Web API и запрашивает данные, а само приложение заняты работой и записью данных. Данные старше 5 минут приемлемы, но могу ли я столкнуться с тупиками или даже ошибочными данными.

Какова лучшая практика здесь. Может быть, 2 разных класса, которые наследуются от DbContext? Разные строки подключения? Другими словами, как мне убедиться, что они не мешают друг другу.

Дополнительная информация

Я должен сказать. У меня есть другое веб-приложение (с почти такой же настройкой, как описано выше), у которого есть задание кэширования при запуске. Это задание выполняется в течение 1,5 часов, только чтение данных, вычисление и сохранение в памяти. Теперь у меня также есть веб-API, который имеет серьезные проблемы, когда работа выполняется в фоновом режиме. Иногда возвращается половина JSON, а иногда и тайм-ауты. Остановка задания кэширования исправляет все.

Именно поэтому я задаю вопрос выше. Не хочу повторять те же ошибки. :)

1 Ответ

0 голосов
/ 06 февраля 2020

Простое решение состоит в том, чтобы все обновления из API выполнялись в одной транзакции. Это решение может ввести блокировку для читателей.
Лучший вариант - загрузить все данные из API в промежуточную область, а затем обновить первичные таблицы с помощью одной транзакции. Если объем данных значительный, вы можете рассмотреть возможность переименования таблиц или «ALTER TABLE SWITCH» при переводе данных в текущее состояние.

...