всё. Понял.

Друзья, такой вопрос: как-нибудь можно сделать так, чтобы метод

ПланыОбмена.ЗарегистрироватьИзменения(МойУзел, МояСсылка)

вызываемый во втором сеансе вставал в ожидание моего (первого) сеанса?
Просто этот метод не генерирует упр. блокировку, а сразу пишет в таблицу изменений через СУБД (там накладывается U). Что такого штатного предпринять в моем первом сеансе, чтобы не допустить добавление записей в таблицу изменений (желательно - только по интересующей меня ссылке, но сойдет вариант и всю таблицу целиком заблокировать)...

накладывать упр. блокировку руками?

перед регистрацией изменения?

Вмешиваться в код параллельных сеансов не хотелось.
Но я что-то еще разок подумал и решил, что исходная потребность в моей ситуации оказалась не нужна, т.к. если регистрация изменения в других сеансах осуществляется вне транзакции записи (объекта, который регистрируется), то действия в моем сеансе не вступают в конфликт с ихней логикой :)
Лучший код - тот, которого нет (с)

Рад поработать уточкой

А что ты там делаешь в своем сеансе, небось удаляешь регистрацию?

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

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

Таких мест нет, т.к. логика выгрузки всех объектов атомарная и независимая. Хвала богам :)
Поэтому и написал выше, что мой код в конфликт с логикой других сеансов (регистрирующих изменения) не вступает.
А вот что делать, если появятся такие места, пока не понятно.

Если возникнет, то отказываться от хранения очереди в таблице изменений в пользу регистра сведений: https://t.me/ssl1c/78703
В теории с таблицей изменений тебе бы нужно было вперед других сеансов успеть обновить запись, которую ты хочешь удалить, новым и известным только тебе номером сообщения. Тогда другие сеансы встанут в очередь на СУБД.
После этого в своем коде считываешь номер сообщения - если там пусто, значит вперед тебя кто-то успел добавить регистрацию и тебе удалять не надо. Если там твой задуманный номер, значит удаляешь и фиксируешь транзакцию.
Но в 1С чтоб проставить произвольный номер сообщения ты должен сначала его обнулить, а после этого ты повторным считыванием уже не отличишь, кто обнулил раньше - твой код или чужой.

Посмотрите в сторону ibcmd , утилита умеет выгружать в dt без подключения к кластеру 1с, а напрямую из СУБД и с активными пользователями. Ее можно запустить вообще на отдельной тачке. До момента выгрузки включается полный план обмена, потом дельту переливаем

На 19 платформе оптимизировали загрузку из dt, для больших баз (100+гб) ускорение по нашим замерам на 20 процентов. Но как я понял сильно зависит от природы данных

Боюсь спросить, как было понятно что именно в регистрации проблема?

А кто-нибудь опенсорсные esb пробовал? Слышал что-то про wso2...

у нас в Связном была

@nixel2007 точно знает)

И чо как? Лайк дизлайк? Как с 1сом подружить?

Да хз. Вроде работала, вроде не тормозила. Но я далеко от нее находился, не могу сказать, с чем сталкивались ежедневно ребята шинщики

Это в каком году то было? обмен был на разнице версий таблиц скриптами сиквела. Очень было радужно, когда нужно было перейти на постгри