Как единица работы используется с пакетной обработкой?

Question

При создании веб-приложения обычной практикой является использование одной единицы работы на HTTP-запрос, сброс всех изменений и фиксация транзакции один раз после обработки запроса.

Какой подход используется, когдастроит пакетный процесс?Используется ли один экземпляр Unit of Work для полного выполнения процесса, когда транзакции периодически совершаются в логических точках?

Это может быть скорее обсуждение, чем фактический вопрос, но я надеюсь выяснить,Существует общепринятая «лучшая практика», аналогичная Session-per-Request.

Answer 1

Единица работы - это ваша бизнес-операция.Определено в области действия ISession.Это должно быть короче;но не слишком короткий.Вот почему рекомендуется использовать Session-Per-Request.Благодаря этому вы можете воспользоваться различными функциями UoW, такими как отслеживание, кэш первого уровня, автоматическая очистка и т. Д. Это может избежать некоторых обращений к базе данных и повысить производительность.

С очень короткими областями ISession, такими как Session-Для каждой операции (вообще без UoW) вы упускаете все упомянутые выше преимущества.

С необоснованно увеличивающейся областью действия ISession, такой как Session-Per-Application ИЛИ группируя несвязанные операции, вы создаете много проблем, таких как недопустимый проксисостояние, увеличение использования памяти и т. д.

Учитывая вышеизложенное, для пакетной обработки попытайтесь определить меньшее UoW в вашей партии.Если вы можете разделить партию на маленькие части UoW, продолжайте.Если вы не можете разделить пакет, у вас есть два пути:

1. Один ISession для всего пакета:
   Если ваша партия обрабатывает одни и те же записи снова и снова, это может быть полезно.С отложенной очисткой вы получите некоторое повышение производительности.
   Даже если ваша партия обрабатывает каждую запись только один раз, это все равно может быть полезно из-за уменьшения количества сбросов и сохраненных обращений к базе данных.См. Пункт 2 ниже.
2. Новый ISession для каждой операции в пакете:
   Если ваша партия обрабатывает каждую запись только один раз, то этот может быть лучше.Я не могу сказать наверняка, поскольку полный сценарий неизвестен.

Оба имеют недостатки, упомянутые выше;лучше попытайтесь найти меньший UoW внутри вашей партии.

Для массовых операций чтения, IStatelessSession - лучшее решение.

Answer 2

Единица работы будет по запросу или короче.(Продолжительность жизненного цикла). Длительный контекст / передача приведет к использованию памяти и проблемам с производительностью.

Если это процесс, во время которого страница активна, пользователь выбирает записи, с которыми нужно работать на более позднем этапетогда в этом сеансе я бы рассмотрел отслеживание выбранных идентификаторов и применимых модификаций на стороне клиента, которые должны быть предоставлены этапу «act» при запуске, или запись простой пакетной записи в состоянии сеанса сервера или в DB для привязки выбранных / измененных объектов.При сохранении в БД должна быть дата-время, связанное с записью, и автоматический процесс для очистки любых необработанных пакетов, которые не были завершены.(пользователь может отказаться, закрыв браузер, например.)

Если бы это был случай, когда нужно объединить записи по многим запросам, например, объединить веб-запросы в группы <= 1000 или запустить процесс каждый разЧерез час я бы использовал постоянную структуру данных, в которой запросы передают данные в структуру пакета, сгруппированную по записи запуска пакета, которая отслеживает текущее состояние пакета.1. Проверьте текущее состояние партии. 2. Если открыто, добавьте / свяжите запись с текущей партией.3. При закрытии / обработке создайте новую партию и свяжите запись с новой партией. </p>

Взаимодействия с партией должны быть пессимистически блокированными, чтобы фоновый процесс не начинал обработку партии во время записи запросов.

Фоновый пакетный процесс запрашивает пакет, чтобы найти пакет, который он должен начать обрабатывать, обновляет статус, обрабатывает и завершает пакет.