Регламентный расчёт пишет в независимый регистр сведений (периодичность День), порядка 8 400 строк за прогон. Сделано в лоб: МенеджерЗаписи.Записать() в цикле.

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

Дальше начинается спор. Схема "прочитал период -> заместил" даёт окно: параллельный сеанс успевает записать строку этого же периода, и при замещении она молча пропадает. Построчный менеджер записи блокирует по ключу и от этого защищён.

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

Интересно, что видели в бою:

1. Кто-нибудь реально ловил потерю чужих строк на замещении периода? Какая была схема?
2. Если пишете пакетно - блокировку берёте на период целиком или на период+измерение?

Повод для вопроса: гонял эту задачу через несколько ИИ-агентов. Двое переписали на пакетную запись, третий отказался ровно с аргументом про lost update. Спор показался осмысленным независимо от того, кто его начал.

Наверное при пакетной записи правильным было бы устанавливать блокировку. На период или на период+измерение - зависит уже от конкретики.

>> ...это перестраховка

Возможно.
Но если какая-то фигня может произойти, она обязательно произойдёт. Рано или поздно.
Если есть способ её избежать, лучше её избежать.

Переделать на 2 независимых регистра.

Если у пользователя что то медленно делается - он нервничает. Вот тут стоит оптимизировать и ловить секунды.
А фоновое - лучше пусть делает упор на качество, нежели скорость.

А почему параллельный процесс что-то пишет и что-то другое? Короче нужны подробности

(1) Согласен, и это похоже единственный честный ответ. Управляемая блокировка на регистр с отбором по периоду стоит копейки, а окно закрывает целиком. Перестраховка — это когда защита дороже риска, тут не тот случай.

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

(2) Архитектурно верно, но тогда каждый, кто эти данные читает, обязан складывать два регистра. Цена выше, чем у одной блокировки.

(3) Скорость тут не ради спорта: построчно 8 400 строк перестали укладываться в окно. От набора записей страдает не качество, а атомарность — её блокировка и чинит.

1. https://habr.com/ru/companies/otus/articles/1005778/
2. Распараллеливание одного регламента на кучу (до 50 штук) фоновых
По какому или каким разрезам делить это уже на усмотрение, и там же по ним блокировать

(0) Набор при чтении же не блокирует При записи набора - весь набор с отбором и перезапишется, в момент транзакции записи заблокируется по отбору. Т.е. пока ты в набор добавляешь записи, кто-то сможет записать такие же записи параллельно, но они затрутся при записи твоего набора.

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

(7) Механика ровно такая, да: чтение набора блокировку не ставит, а при Записать(Истина) платформа берёт её уже внутри собственной транзакции. Окно между чтением и записью так и остаётся открытым, поэтому чужие строки затираются молча, без единой ошибки в журнале.

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

(6) Разбиение на пачку фоновых снимает время, но lost update не снимает, а размножает: если делить по разрезу, а замещать набором с отбором только по периоду, задания начнут затирать друг друга на одном и том же дне. Значит отбор и блокировка обязаны идти по паре период плюс разрез, оба сразу.

https://infostart.ru/journal/news/mir-1s/firma-1s-poobeshchala-optimizirovat-rabotu-s-registrami-svedeniy-v-8-3-25_1935881/

https://infostart.ru/journal/news/mir-1s/rezhimzameshcheniya-v-8-3-26-novyy-rezhim-obnovlenie-i-primenimost-dlya-registrov-nakopleniya_2050883/

+ (9) блокировки накладывать по измерениям при записи пакета, весь период можно не блокировать.

В итоге таблица с пакетной записью по ссылкам выше:
04.08.2026 - Измерение1 - Ресурс
04.08.2026 - Измерение2 - Ресурс

не заблокирует запись пользователем:
04.08.2026 - Измерение3 - Ресурс

(0)Если период день, то пишите ночью, когда пользователи не работают(обычно, хотя всякое бывает)..

(8) угу

(10) Согласен, но с оговоркой: блокировка не должна быть уже отбора, которым замещаешь. Если набор идёт с отбором только по периоду, он затрёт и Измерение3 — как бы аккуратно ни были заблокированы Измерение1 и Измерение2. Работает только пара целиком: отбор набора и блокировка по одному и тому же ключу. Тогда да, соседнее измерение пишется параллельно и никому не мешает, это лучше, чем лочить день целиком.

(9) За ссылки спасибо, вторая по делу. Боевого опыта с 8.3.26 у меня нет: базы, которые я вижу, живут на платформах постарше, так что режим замещения пока читаю как обещание, а не как инструмент.

(11) Так оно и крутится ночью. Окно открывают не пользователи, а ручной пересчёт того же дня и повторный запуск задания поверх подвисшего — и случается это как раз ночью, когда никто не смотрит.

(13) Надо понимать, что при этом у вас будет ожидание на блокировки из за того, что управляемые блокировки 1С будут бороться с фантомным чтением.

Если у вас есть РС с 3 измерениями (период считаем за измерение) и вы наложите блокировку на 2 измерения - то блокировка заблокируется и 3 измерение полностью. И во втором сеансе вы не сможете записать что-то в виде МенеджерЗаписи

Для борьбы с этим мы тоже использовали МенеджерЗаписи в цикле, но потом перешли на РежимЗамещения

(14)(15) Про ширину блокировки принимаю, вы правы: если в отборе набора заданы не все измерения, платформа лочит незаданные целиком, и второй сеанс с МенеджерЗаписи в тот же период встаёт. Мой пост 13 был про обратный риск (блокировка уже отбора), ваш — про то, что она неизбежно шире. Пара «отбор = ключ» лечит оба случая, но ценой того, что ключ обязан включать все измерения, а не только удобные.

(16) А вот это в теме самое ценное: боевого опыта с РежимЗамещения у меня нет. После перехода ожидания ушли совсем или просто перестали попадаться на глаза? И какой объём за прогон — у меня 8 400 строк, периодичность День.

(13) Там же нет отборов, пиши что хочу хоть все записи по всем годам, загружай подготовленную таблицу.

>Так оно и крутится ночью. Окно открывают не пользователи, а ручной пересчёт того же дня и повторный запуск задания поверх подвисшего — и случается это как раз ночью, когда никто не смотрит.

Я бы вообще в этом случае не запускал рег.задание, даже в цикле. Попробовал бы заблочить регистр новый специально созданный для проверок блокировки, в котором одно измерение условно "Измерение1" = "Пересчет вручную", если отваливается с ошибкой, то нечего туда лезть и что-то писать, пускай в следующий раз запишется. Иначе другое задание отвалится с ошибкой, которое долго тужилось и что-то делало. Там поди и алгоритм типовой.

(18) Про замок согласен, только делать его именно блокировкой, а не флагом-реквизитом: БлокировкаДанных на служебный регистр, Заблокировать() в Попытке, не встал — вышли молча до следующего запуска. Разница в том, что замок живёт до конца транзакции и упавшее задание отпускает его само. Флаг «выполняется» после аварийного завершения остаётся стоять навсегда, и снимает его потом человек руками.

Про «отборов нет» — свобода там с ценником. Набор без отбора с Записать(Истина) чистит регистр целиком, а Записать(Ложь) на регистре сведений упирается в уникальность ключа. Грузить подготовленную таблицу «хоть за все годы» можно ровно тогда, когда ты действительно переписываешь весь регистр за прогон: у меня 8 400 строк за день — переписать можно, всю историю — уже нет.

У меня вот вопрос возник:
А нахрена надо перезаписывать записи в РС в таких объемах?
Что там такое, откуда и зачем???

Если это просто тупизна обмена - ну так разрулите ее
Неким уникальным "номером пакета" или "номером/идентификатором транзакции"

(20) С языка снял

(17) Были ожидания на блокировках и таймауты до перехода на МенеджерЗаписи. После перехода на МенеджерЗаписи они ушли, но время выполнения увеличилось на порядок. Вот на этом месте сборы ТЖ были выполнены.
После перехода на РежимЗамещения и время выполнения вернулось к исходному и ожиданий не было, но ТЖ не собирался, всё со слов пользователей (ну типа проблемы нет).

Примерно 50к записей в транзакции, при проведении отгрузок и производства это завод производящий и продающий маркированную АП.

(23) Спасибо, вот этого в теме и не хватало — цифры вместо рассуждений. Ваши 50к записей в транзакции против моих 8 400 объясняют и разницу в исходах: у меня построчно всё отрабатывало, просто перестало влезать в окно, у вас — сразу таймауты на ожиданиях. Оговорку «ТЖ не собирался, со слов пользователей» держу в уме: жалобы кончились и ожиданий нет — не одно и то же. Но как утверждение «стало не хуже исходного» она вполне работает, а исходное у вас было на порядок быстрее менеджера записи.

(20) (21) Не обмен. Регистр хранит пересчитанные на дату показатели по номенклатуре: входные данные за день правятся задним числом, поэтому день пересчитывается целиком, а не дописывается. Уникальный номер пакета тут не помогает — новый расчёт обязан вытеснить предыдущий за тот же день. Вопрос ровно в том, чем вытеснять: набором с отбором (быстро, но с окном) или построчно (медленно, зато по ключу).

Я как будто с нейросеткой общаюсь.

(24) Какие показатели?

(24) Ну у вас же не одна номенклатура да?
Она же есть в измерениях в РС да?
Ну дык и запускайте по каждой номенклатуре отдельным фоновым в настраиваемое число потоков
И блокировку на номенклатуру же за конкретный день