У документа есть подписка на событие обработка проведения. В рамках неё происходит пара "тяжёлых" запросов и создание подчинённых документов за записью ссылки в них. Я бы хотел поместить весь тяжёлый код в фон (делал через БСП - длительные операции), но в рамках новой, фоновой транзакции, изменения в базе данных не видны. С подобным уже сталкивался, решил сериализацией табличных частей и нужных мне реквизитов в структуру и передачу её параметром. Тут такое не пройдёт - придётся слишком много чего переписывать. Кто-нибудь сталкивался с такой проблемой и есть ли изящное решение без ухода в регламентное задание?

"В рамках неё происходит пара "тяжёлых" запросов и создание подчинённых документов за записью ссылки в них" - поубивав бы..

(1) Согласен, но писал не я. Моя задача это всё дело максимально ускорить минимальными усилиями :)

(1) легко решается запуском фонового задания

(3) ну, не так уж и легко если есть проблемы как в (0). Или речь про регламентное? Мне оно не подходит.

(0) >>создание подчинённых документов за записью ссылки в них
Запись ссылок куда?

"изменения в базе данных не видны" - можно более подробно где именно они не видны? В открытых формах?

(0) Как собираешься отменять создание подчиненных документов при отказе проведения основного документа?

(7) + 1

(7) Вызовом ещё одного фонового задания, "обратного" первому. "Я тебя породил, я тебя и убью"(с)

(5) Там перекрёстно у нового документа в проводимы и назад.

(7) Для этого это делается последней подпиской в самом конце с проверкой на отказ.

(6) При чём тут формы? Записывается объект. Скажем, если это новый объект, то в подписке в обработке проведения ссылка на него уже будет существовать. И запросом можно выбрать его табличную часть, например. В фоновом же задании открывается новая транзакция, ссылка будет на новый пустой документ, а запрос по табличной части ничего не вернёт.

(11) а если потом кто то добавит еще одну подписку?)

(13) Надавать ему по пальцам :) Если серьёзно, в этом плане у нас есть защиты от таких коллизий. Доработки по подпискам, которые влияют от отказов или могут к ним приводить все запихнуты в 1 процедуру на каждый документ, который стоит в конце. По (0) у кого-нибудь мысли есть? Не хочется ради такой мелочи перелопачивать всё :(

(12) фоновое же ты запускаешь в самом конце подписки и транзакция проведения должна завершиться?

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

Можно поэкспериментировать и паузу в 1 секунду добавить :-D Но это не решит ту же проблему с переданной ссылкой в параметре. Объект в фоновое задание не запихнуть параметром.

(16) Не просто отельную транзакцию, а отдельный сеанс.
Нужно в фоновом дождаться, пока основная транзакция зафиксируется и изменения будут видны.

(12) Sorry, понедельник, утро... Чисто теоретически, сам объект --> ПоместитьВоВременноеХранилище(), без движений документа.
Некрасивое решение: можно скопировать и записать в базу; после использования в фоновом задании - удалить.

(18) Я это и имел ввиду, верно, там сеанс запускается. Возможно ли передать ссылку нового документа при этом?

(19) чёт оба варианта какие то ужасные, но за наводки спасибо. Сам объект мало что даст и не лучше варианта с сериализацией.

(17) Можно попробовать отвязаться от самого документа. И запускать фоновое задание из другого места. Например из РС или РН связанных с твоим документом.

Кстати интересно, а что с ссылкой у объекта, который поместили во временное хранилище? Что вообще с ним происходит при помещении туда?

(24) вот это интересная идея, спасибо, подумаю.

(25) Чисто теоретически рассуждая, если учитывать что документ может быть записан без проведения, то самой ссылкой уже можно пользоваться в процедуре ПриЗаписи(), которая вызывается до ОбработкаПроведения().

(11) Нет такого понятия "последняя" подписка. Хоть практика показывает, что подписки на одно событие для объекта запускаются в порядке следования в дереве метаданных платформой не регламентирован порядок запуска. И завязываться на это нельзя.

(16) Проблема известная - платформа не имеет механизма запуска события "после окончания транзакции". Когда поднимется Infostart кину ссылку на статью. Может поможет.

В общем случае советую разнести события: после создания основного документа формировать очередь задания на создание подчиненнных (связанных) и отдельным заданием ее обрабатывать.

(20) А в чем проблема передать ссылку?

"А в чём проблема"(с) не использовать механизм отложенное проведение? :)

(29) Для новых объектов её сеанс\транзакция фонового задания её не видит.
(28) Пока мне больше всего понравилась идея привязаться к РН и просто от него плясать. Тыркать регистратор не совсем красиво, конечно. Да и следующий кто будет разбираться где создаётся документ - прифигеет это искать. Гм, надо ещё подумать)

(31) Еще раз повторю (18):

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

(32) ок интереса ради поиграюсь с паузой секунд в 5 как дойдут до этой задачи.Но даже если это поможет, решение выглядит ненадёжным.

(33) Просто пауза конечно ненадежно. Нужно проверять запросом.

(34) Да, ты абсолютно прав. Ожидание в несколько секунд решило проблему, и ссылку он определяет правильно. Видимо, он просто по ней не мог данные получить. Остаётся только дилемма как обезопасить схему и как не уйти в бесконечный цикл. Ну, это уже мои проблемы. Спасибо.

Хех... а если тупо и без затей использовать ТранзакцияАктивна() для постановки фонового задания на "паузу"?

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

(37)+ А на все проверять как то страшновато.

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

+(28) https://infostart.ru/1c/articles/1243723/

(31) Лучше создать РС где записи это документы требующие обработки.

(40) Спасибо.
Кому интересно, сделал в итоге так. Работает неплохо, но некоторая уязвимость всё равно есть.
В фоновую процедуру передаётся ДокументСсылка - ссылка на документ и ВерсияДанных - свойство ссылки. Затем внутри самой процедуры я их сверяю, если не совпадают - жду три секунды.

    ЧислоПопыток = 0;
    Пока ЧислоПопыток < 5 Цикл
        ЧислоПопыток = ЧислоПопыток + 1;    
        Если Версия = ДокументСсылка.ВерсияДанных Тогда  
            Прервать;
        Иначе
            Если ЧислоПопыток = 5 Тогда
                Возврат;
            КонецЕсли;  
            ОбщегоНазначенияБТС.Пауза(3);
        КонецЕсли;
    КонецЦикла;

(42) А что, версия данных всегда меняется? :)

в фоновом задании начинай транзакцию и пробуй установить блокировку на документ. как только транзакция записи/проведения документа завершиться - блокировка установится и все будет как надо.

(42) фубля

(43) Когда есть изменения в документе документе - да, всегда. Если изменений не было, то и ждать не надо.
(44) Какой тайм-аут у блокировки?

(46) стандартный от базы, секунд двадцать. но если ты в себе уверен, то ты можешь это всё делать в цикле

(47) Тогда не вижу принципиальной разницы кроме стилистической. Что там отвалится через 20 секунд в случае проблем что тут через 15. Блокировать саму запись мне не нужно - там в основном только чтение в запросе идёт. Самое грамотное решение было бы через РС и регламентное сделать, пожалуй, но пока мне это не подходит, если и буду переделывать в эту сторону, то потом и сразу всё. Сейчас просто попросили сделать что б посмотреть насколько это юзерам ускорит работу и стоит ли в этом направлении вообще двигаться.

(48) принципиальная разница в скорости реакции (от окончания транзакции проведения документа до установки блокировки миллисекунды пройдут), независимости от ВК, работу не через "а мы уже приехали? а сейчас?".

(49) Хорошая аналогия 😃 С одной стороны соглашусь, что так лучше и изящнее, с другой всё-таки опасаюсь нарваться на исключительную реакцию при блокировке. А если нагромождать попытками, то выйдет не лучше. Пока оставлю как есть, но за мнение спасибо)