Enterprise data , Блокировка данных зарегистрированных на узлах при одновременном выполнении сценариев обмена

Добрый день!
Возникла ошибка с обменами Enterprise data : Ошибка установки блокировки на обмен данными. Возможно, обмен данными выполняется другим сеансом.

Прошу помощи в диагностике и методических рекомендаций по оптимизации.

Вопросы:
1) Есть ли возможность выполнять сценарии обмена в типовых обменах Enterprise data только при наличии зарегистрированных объектов на узле. Текущая настройка какую мне удалось реализовать даже в случае если передавать нечего осуществляет подключение к периферийной базе даже в случае если зарегистрированных объектов к передаче нет.
2) Есть ли блокировка объекта объекта зарегистрированного на узле во время выполнения сценария Enterprise data , как это отключить и целесообразно ли , каковы риски этой доработки, какую цель преследует блокировка если она есть?
Как выяснить связана ли природа ошибки приведенной тут (полный текст ошибки в конце) с
3) Прошу архитектурных рекомендаций, как оптимизировать/ рефакторить сушествующий обмен. Сейчас как транспорт выбран COM. Аргументы за него : все базы в одной быстрой локальной сети, аппаратные ресурсы большие, и база УХ довольна свежая и маленькая (20к справочников, 10к документов, размер до 35гб), переносятся однонаправленно довольно небольшие данные . не надо публиковать Периферийные базы скажем для транспорта HTTP (XDTO по Http вроде бы типовые обмены умеют, JSON по http – доработки).
Есть ли у меня шансы остаться на COM при допустим маштабировании задачи этого обмена на 120 внешних периферийных баз и какое решение целесообразнее выбрать?


Описание проблемы :
периодически в течении дня в базах с которыми проводится обмен по расписанию из УХ появляются зависшие соединения пользователя под которым к ним подключается УХ, таких соединений может накапливаться за сутки по 50-70, баз подключенных к УХ около 40.
Сервер начинает тормозить, серверные базы периодически становятся недоступны до действий: « отключить регламентные задания на сервере»- «Сбросить регистрацию на узлах если она сильно избыточна»(скажем более 3к объектов)- «Отключить зависшие сеансы COM».

Зависшие соединения висят сутки и отваливаются по таймауту 86400 установленному на базе , На файловых проблема не проявляется.
Зависшее подключение в периферийную базу забирает свободную лицензию и вероятно конкурирует с пользователем за ресурсы (в рамках лицензии ПРОФ на сервер1с)

Я предполагаю что зависший сеанс на сервере у меня получается в результате ошибки блокировки, но природа мне не понятна, вероятно регламентное задание обмена в УХ корректно не закрывает соединение и так у меня получается зависший сеанс.
Характер регистрации справочников носит лавинообразный характер для контрагентов которые имеют договоры с многими организациями . (Например записали контрагента Мосэнергосбыт, он зарегистрировался на всех узлах со всеми своими банковскими счетами + договоры по организации)
Те при очередном выполнении рег задания одни и те же справочники будут переноситься в периферийные базы (БП3). И очень часто в один момент времени один и тот же объект переносится в несколько периферийных баз, периферийных баз 40шт с расписанием раз в 10-15 минут, в один момент времени в среднем выполняется 2-5 сценариев синхронизации с периферийными базами (БП3).

Описание реализованного обмена:
Однонаправленный обмен для переноса банковской выписки из УХ в периферийный базы + централизованное управление справочниками.
УХ – типовая и обмен ведется с 40-ка типовыми БП3. Тип соединения –прямое подключение к базе (Через COM). Настроены сценарии выполнения рег. заданий обмена 1 раз в 12 минут.
Обмен реализован через единый план обмена «Обмен данными через Универсальный формат». Создано 40 узлов для БП3 и в каждом определены Организации.
Сервер и клиентские лицензии 1С ПРОФ, Сервер x64 ПРОФ.
Переносимые данные и сценарий регистрации данных:
Обмен реализован для централизованного управления справочниками в периферийных базах и переноса документов банковской выписки из УХ в БП.
Управление холдингом является первичной точкой ввода для справочников Контрагент, Договор, Банковский счет.
Регистрация Справочников Контрагент и Договор на узлах определяется наличием Договора с Организацией
Договор – по организации ( если есть договор с ООО ромашка то регистрировать на узле с организацией ооо ромашка)
контрагент - регистрируется на узлах организаций с кем у него есть договор
Банковские счета - регистрируются на узлах организаций на которых зарегистрировался Контрагент .
Документы банковской выписки регистрируются на узлах по организации.

Описание ошибки в ЖР:

Произошла исключительная ситуация (1C:Enterprise 8.3.20.1789): {ОбщийМодуль.ОбменДаннымиXDTOСервер.Модуль(1573)}: Ошибка установки блокировки на обмен данными.
Возможно, обмен данными выполняется другим сеансом.

Подробности:
Ошибка блокировки объекта. Объект уже заблокирован:
компьютер: $$-srv-db1, пользователь: 1C_$$h, сеанс: 4133, начат: 04.07.2022 в 12:51:56, приложение: COM-соединение
{ОбщийМодуль.ОбменДаннымиСервер.Модуль(6921)}:ОбработкаОбменаДаннымиВнешнееСоединение.ВыполнитьВыгрузкуДанных(ОбработкаДляЗагрузкиДанных);
{ОбщийМодуль.ОбменДаннымиСервер.Модуль(5262)}:ВыполнитьДействиеОбменаДляУзлаИнформационнойБазыПоВнешнемуСо­единению(ОтказПоСтрокеСценария,
{ОбщийМодуль.ОбменДаннымиСервер.Модуль(5352)}:ВыполнитьОбменДаннымиПоСценариюОбменаДанными(Ложь, Выборка.Ссылка);

по причине:
Произошла исключительная ситуация (1C:Enterprise 8.3.20.1789): {ОбщийМодуль.ОбменДаннымиXDTOСервер.Модуль(1573)}: Ошибка установки блокировки на обмен данными.
Возможно, обмен данными выполняется другим сеансом.

Подробности:
Ошибка блокировки объекта. Объект уже заблокирован:
компьютер: $$-srv-db1, пользователь: 1C_$$h, сеанс: 4133, начат: 04.07.2022 в 12:51:56, приложение: COM-соединение
по причине:
Произошла исключительная ситуация (1C:Enterprise 8.3.20.1789): {ОбщийМодуль.ОбменДаннымиXDTOСервер.Модуль(1573)}: Ошибка установки блокировки на обмен данными.
Возможно, обмен данными выполняется другим сеансом.