Фоновые задания. Превышение времени предоставления блокировки #721019

Уважаемые форумчане! Столкнулся со следующей проблемой. В некой функции строю дерево партий (из партионного учета) со всеми цепочками преобразований (через отчеты производства за смену, комплектации) - некий локальный расчет себестоимости. Переделал разузлование на фоновых заданиях, которые запускаются при уровне выше второго. Но во время работы фоновых заданий есть таблица, которая хранит в себе данные "цепочек" - с документом оприходования и документом списания и количеством. Данные в ней должны быть синхронизированы: сначала я читаю данные в этой таблице, потом записываю. Эта таблица сделана на непериодическом РС. И постоянно фоновые задания падают на методе Прочитать. Как правильно разруливать блокировку? Там таблица из трех записей, вот же ж. И все равно падает.

Сделал вот такую штуку с блокировкой. может, не правильно?

Это обрезанная функция, не обращайте внимания на параметр "ТаблицаНакопленных". Вся эта механизма работает в рекурсии. Функция "НакопитьДвижение" вызывается из функции, где перед этим идет вот такой блок: ... То есть, я сначала читаю остаток в этом регистре, потом его дописываю. Излишняя блокировка получается.

Убрал процедуру НакопитьДвижение и засунул все сюда ... КонецПроцедуры Все равно падает...

режим блокировок какой?

Управляемый, конечно.

Если управления не получается, видимо - НЕуправляемый и НЕконтролируемый...

интересно с другой стороны кто блокирует

Попробуй

Апну ветку. Господа! Я не уточнил, что это все делается в обработке проведения. Если эту функцию вывести отдельно, то все работает без проблем. Вопрос: почему в обработке проведения фоновые задания блокируются? У документа режим управления блокировкой выставил в управляемый.

Твою стипендию! С этого и начинать нужно было! Сам себе заблокировал в транзакции проведения, а другим сеансом накладываешь тоже самое.

А где то в настройках сеанса можно увеличить это время предоставления блокировки?

можно даже программно

Глобальный контекст (Global context) УстановитьВремяОжиданияБлокировкиДанных (SetLockWaitTime) Синтаксис: УстановитьВремяОжиданияБлокировкиДанных(<Таймаут>) Параметры: Тип: Число. Время ожидания блокировки данных (в секундах). Значение по умолчанию: 20 Описание: Устанавливает время ожидания блокировки данных (в секундах). Доступность: Сервер, толстый клиент, внешнее соединение.

В том-то и загвоздка, что фоновым заданиям вообще пофиг на проводимую реализацию в родительском сеансе. Если убрать этот регистр, то фоновые задания отрабатываются нормально. Это регистр нужен для синхронизации данных, отрабатываемых разными фоновыми заданиями. Я тестировал без него - никаких проблем с блокировками. Выходит, вся проблема в данном регистре, но в родительском сеансе к нему нет обращений. ЧЯДНТ?

документ подичиненый регистратору? удаление движений авто? в регистр пишешь в "родительском" сеансе?

В смысле регистр? Не, неподчиненный. В родительском этот регистр вообще не используется. Кстати, заметил, что результаты, выполненные в одном потоке и асинхронно различаются. Не сильно, но разница есть. Походу, ошибка в логике где-то :(

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

концепт такой: обработка проведения -> старт фонового задания 1 фоновое задание 1 - делим данные на независимые порции, стартуем фоновые задания 2...К на каждую порцию или не более чем Х штук в цикле пока порции не закончатся. ждем окончания Фоновые задания 2...К пишут в независимый регистр результаты своей работы фоновое задание 1 - собирает результаты, очищает регистр-буфер, записывает набор движений исходного документа.

ААААА, понял. У меня нет этого "прокси" - фонового задания 1. Кстати, можно подключить обработчик ожидания (имхается мне) и там стартануть все это дело. Но вот вопрос: а если будет эксепшн, как этот вопрос разрулить? (Движения тогда не запишутся)

Синтаксис: ОжидатьЗавершения(<ФоновыеЗадания>, <Таймаут>) Параметры: Тип: Массив. Массив фоновых заданий, завершение которых нужно ожидать. Тип: Число. Таймаут в секундах ожидания завершения заданий. Если таймаут не задан, ожидание будет длиться до завершения всех заданий, или до первого аварийного завершения задания. Описание: Ожидает завершения всех фоновых заданий из списка. Если хотя бы одно задание завершено аварийно, ожидание прерывается и выдается ошибка выполнения задания. Если наступил таймаут, выдается ошибка ожидания задания. Ожидать завершения заданий может только администратор или пользователь, запустивший задания на выполнение. Доступность: Сервер, толстый клиент, внешнее соединение.

вот тут тоже без проксизадания, но мало ли:

Я как раз эту процедуру юзаю в обработке проведения. Если она выполнится, тогда отрабатываю данные, если "отваливается" провожу без фоновых заданий. Так вот после добавления этого регистра, обеспечивающего синхронизацию - она всегда отваливается. Даже одно фоновое задание нельзя запустить. Почему так?

забей на обработку проведения, делай все вне транзакции

иначе будет косяк

ну ты видимо юзаешь какие-то заблокированные ресурсы из незакрытой транзакции записи-проведения документа, и при этом сам себе дедлок делаешь

Ок, я понял. А как проверить, что фоновое задание отработало нормально? Видится мне мне, что что-то вроде Пока Не проведенПравильно Цикл завернуть в попытку, а при исключении проведенПравильно = ложь и так до бесконечности:) Или ограничиться несколькими попытками и вывести в ЖР.

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

+ только в случае косяка - надо не совсем отменять, а восстанавливать предыдущее состояние, что немного сложнее