← На главную

При разработке сложных учетных систем часто возникает нетривиальная задача: необходимо убедиться, что транзакция проведения документа (или записи объекта) полностью завершена, данные зафиксированы в СУБД, а блокировки сняты. Только после этого мы можем безопасно инициировать ресурсоемкие процессы, например, расчет себестоимости, который может длиться по несколько минут. Если запустить такой расчет до фиксации транзакции, мы либо прочитаем старые данные, либо столкнемся с конфликтом блокировок.

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

Вариант 1: Использование фонового задания и проверка ВерсииДанных

Если мы находимся в модуле объекта (например, в ОбработкаПроведения), мы не можем просто подождать окончания транзакции, так как наш код выполняется внутри нее. Платформа 1С не имеет встроенной функции ожидания фиксации текущей транзакции для соседних потоков.

Проанализируем решение, предложенное в обсуждении: использование механизма фоновых заданий с контролем изменения версии данных.

1. В процедуре ОбработкаПроведения мы считываем текущую (уже измененную в памяти) версию данных объекта — ВерсияДанных.
2. Мы запускаем фоновое задание, в параметры которого передаем ссылку на наш документ и полученную ВерсияДанных.
3. Внутри фонового задания (которое выполняется в отдельном сеансе и отдельной транзакции) мы запускаем цикл. Раз в секунду мы читаем запросом текущую версию данных этого документа из базы данных.
4. Как только версия данных из базы данных совпадет с переданной версией (или станет новее), это будет служить 100% маркером того, что основная транзакция проведения зафиксирована в СУБД.
5. После совпадения версий мы смело начинаем наш тяжелый расчет.

Вариант 2: Использование события формы ПослеЗаписиНаСервере

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

В управляемых формах 1С существует четкая последовательность вызовов событий. Событие ПриЗаписиНаСервере выполняется еще в рамках транзакции записи объекта. А вот обработчик ПослеЗаписиНаСервере вызывается строго после того, как транзакция записи в СУБД закрыта.

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

Вариант 3: Паттерн "Очередь заданий" (Отложенное проведение)

Посмотрим на пример современных типовых конфигураций, таких как 1С:ERP или 1С:Комплексная автоматизация. В них проблема длительных расчетов решается архитектурно, через механизмы очередей.

Суть подхода заключается в следующем:

1. Тяжелые действия (в нашем случае — 10-минутный расчет себестоимости) полностью исключаются из транзакции проведения документа.
2. В модуле проведения документа формируются только самые необходимые и быстрые оперативные движения. Затем в специальный служебный регистр сведений (Очередь) записывается маркер-задание: "Для такого-то документа требуется расчет себестоимости".
3. Транзакция проведения завершается за доли секунды, пользователь может продолжать работу. Маркер успешно зафиксирован в базе.
4. Отдельное регламентное задание (или постоянно работающий фоновый поток) регулярно читает эту очередь. Обнаружив новую запись, оно берет ее в работу и выполняет тяжелый расчет полностью независимо.

В интерфейсе документа при этом можно выводить статус, например: "Ожидает расчета себестоимости" или "Состояние: рассчитывается".

Вариант 4: Современный метод ЗапланироватьВТранзакции()

Если мы используем современные версии платформы или паттерны БСП, мы можем воспользоваться механизмом планирования заданий непосредственно внутри активной транзакции.

Логика метода ЗапланироватьВТранзакции() очень элегантна. Мы вызываем эту команду прямо в обработке проведения. Система принимает команду, но физически запускает фоновое задание только после успешного завершения текущей транзакции.

Если по какой-то причине транзакция документа откатывается (произошла ошибка, сработал отказ), то и запланированное задание автоматически аннулируется. Это избавляет нас от необходимости вручную проверять, успешно ли завершилось проведение.

Архитектурное замечание: почему транзакций по 10 минут быть не должно?

В завершение выясним причину возникновения описанной проблемы. Если документ проводится 10 минут — это серьезный архитектурный дефект (антипаттерн). Согласно стандартам разработки 1С, длительных транзакций следует избегать любой ценой.

Пока длится 10-минутная транзакция, СУБД удерживает транзакционные блокировки на все таблицы и регистры, которые читает или в которые пишет этот документ. Это парализует работу других пользователей в системе (возникают ожидания на блокировках и конфликты, о которых упоминалось на форуме при вызове метода ПолучитьОбъект() в соседнем сеансе).

Оптимальным решением будет пересмотреть саму концепцию проведения: сделайте проведение "быстрым", а весь тяжелый расчет вынесите в отдельную операцию. Используйте очереди заданий (как в Варианте 3) или длительные операции из Библиотеки стандартных подсистем (БСП) с отображением прогресс-бара пользователю. Это обеспечит стабильность базы данных и комфортную работу пользователей.