Всем привет.
Наткнулся на очень странный "типовой" код, который ввёрг меня в ступор.

Имеется подписка на событие при записи документов, входящих в план обмена.
В ней происходит регистрация изменений.
А при успешной регистрации происходит вызов фонового задания по отправке изменений через WS.

Мало того, что выгрузка дока происходит асинхронно независимо от успешности записи текущей транзакции, так ещё и бессмысленная блокировка ставится. Или тут есть сакральный смысл?
---
Судя по всему, блокировка тут лишняя, хотя прямого ответа я так и не услышал.
А регистрацией разобрались, хотя, она итак работает, просто неоптимально.
---
Сроки действия управляемой блокировки знаешь?
---
ну тут явно не "типовой" код, в частности регистрация в плане обмена происходит не так, если операция проходит в транзакции, достаточно указать нужный план обмена как "получатель" в свойствах обмен данными. тогда при успешной транзакции объект будет зарегистрирован к обмену.
---
Вопрос то был про блокировку.
И чем это "профитней", чем ЗарегистрироватьИзменения()?
---
Повторю за коллегой, которому вы отвечаете: весь этот якобы "типовой" код не нужен. И зарегистрироватьизменения и, тем более, блокировка.
---
весь этот якобы "типовой" код не нужен. И зарегистрироватьизменения
вы наверное в этом 1с и работаете?
---
Я работаю в конфигураторе. А код видимо ваш, раз вы начали его защищать методом перехода на личности?
---
Отвечаю на вопрос по бессмысленности блокировки

 1. Платформа 1С обеспечивает режим многопользовательской работы приложений
 2. Запись документов по плану обмену осуществляется в результате транзакции переноса данных
 3. Т.к. режим многопользовательский, то документы могут быть изменены во время транзакции кем либо из пользователей, транзакция может быть не одна.
 4. а) если одна транзакция несколько раз считывает одни и те же данные, а вторая - вносит изменения в эти данные между циклами чтения данных первой транзакции, то при повторном считывании первая транзакция может получить другой набор данных.
 б) если первая транзакция считывает данные и потом на их основе осуществляет определенные действия, а вторая транзакция в этот момент добавляет в эти данные новую информацию, то как и в предыдущем случае это может привести к некорректному результату.
 5. В современных СУБД решение задач, изложенных выше , в п.4, реализуется путем применения уровней изоляции транзакций. Но зачастую такой подход приводит к возникновению «плохих» (избыточных) блокировок и не позволяет достичь желаемой параллельности работы пользователей.
 6. В 1С:Предприятии версий 8.1 и выше реализован дополнительный режим работы, позволяющий использовать собственный менеджер транзакционных блокировок 1С:Предприятия, независимый от используемой СУБД, реализуемый с помощью режимов: "Автоматический", "Управляемый" и "Автоматический и управляемый", которые устанавливаются для конфигурации и объектов конфигурации, причем режимы, установленный для конфигурации, может не совпадать с режимом, установленным для объекта конфигурации
 7. НО, если существующая транзакция начата в управляемом режиме, то начинаемая транзакция может быть выполнена только в том случае, если для нее также указан управляемый режим. Если для нее указан автоматический режим - будет вызвана исключительная ситуация.
 8. Если разработчик открывает транзакцию в управляемом режиме, то он должен быть уверен в том, что для записываемого в этой транзакции документа, в свойствах метаданных указан управляемый режим блокировок в транзакции. В противном случае при записи элемента справочника будет вызвана исключительная ситуация. Поэтому в тексте блокировки указан режим, при котором она работает: Режим.Блокировки.Данных.Исключительный;

Вывод: Указанная блокировка не является бессмысленной.

Источник информации: https://its.1c.ru/db/metod8dev/content/5839/hdoc - здесь можно прочитать более подробно
---
В огороде - бузина, а в Киеве - дядька. К обсуждаемому вопросу ваш текст и ссылка не имеют отношения.
---
конечно,куда важнее что например регистрация изменений в план обмена не нужна. зачем регистрировать какие то изменения вообще
---
Это не так работает: достаточно указать нужный план обмена как "получатель" в свойствах обмен данными.
---
Можно и через ЗарегистрироватьИзменения() - не вижу криминала. А вот блокировка тут очень "странная". Не понятно, зачем она, и что хотел сделать её автор.
---
Это как с движениями, можно записывать самому, но лучше отдать на откуп платформе: меньше кода и порядок блокировки регистров одинаковый.
---
Правильно ли я понял, что если есть возможность сделать регистрацию объекта при его записи, то лучше воспользоваться Свойством "Получатели", а если её нету (например, при записи упаковки регать её номенклатуру), тогда православным старым методом ЗарегистрироватьИзменения()?
---
Да, примерно для таких случаев и используется ЗарегистрироватьИзменения
---
Судя по всему, блокировка тут лишняя, хотя прямого ответа я так и не услышал.
А регистрацией разобрались, хотя, она итак работает, просто неоптимально.