Сколько живет COM-соединение 1С и как управлять его временем жизни

COM-соединение 1С (объект V83.COMConnector или V82.COMConnector) не имеет фиксированного «срока жизни» в секундах или минутах. Соединение существует, пока жив клиентский объект-коннектор, пока сервер 1С не разорвал сеанс по тайм-ауту или пока соединение не закрыто явно. На практике это означает: время жизни определяется тремя факторами — настройками кластера серверов 1С, поведением клиентского кода и стабильностью сети.

Чаще всего вопрос «сколько живет COM-соединение» возникает в двух ситуациях: либо внешняя программа (скрипт, служба, другая база 1С) периодически теряет связь с базой и выдаёт ошибки, либо на сервере копятся «зависшие» сеансы от COM-подключений, которые занимают лицензии и память. Оба случая связаны с одним механизмом — управлением временем жизни сеанса, который создаётся при COM-подключении.

Ниже разобрано, что именно происходит с соединением после установки, какие тайм-ауты на него влияют, как диагностировать преждевременный разрыв и как правильно закрывать подключение, чтобы не плодить «мертвые» сеансы.

Что происходит при установке COM-соединения

Когда внешнее приложение вызывает метод Connect объекта COMConnector, на сервере 1С (или в файловой базе — в процессе клиента) создаётся полноценный сеанс. Этот сеанс занимает программную лицензию, выделяет память в рабочем процессе rphost и регистрируется в консоли кластера так же, как сеанс обычного пользователя тонкого клиента.

Сам COM-объект на стороне клиента — это лишь «ручка» (proxy) к этому сеансу. Пока переменная, содержащая соединение, существует и периодически используется, сеанс считается активным и живёт неограниченно долго. Проблемы начинаются, когда соединение простаивает: сервер 1С и операционная система начинают применять к нему механизмы очистки неактивных ресурсов.

Какие тайм-ауты определяют время жизни соединения

Основные параметры находятся в свойствах кластера серверов 1С (консоль администрирования, свойства кластера). Два ключевых значения: «Интервал завершения неактивных сеансов» и связанный с ним механизм перевода сеанса в спящее состояние. По умолчанию неактивный сеанс переводится в спящий режим, а спящий сеанс завершается принудительно по истечении заданного интервала.

Типовые значения по умолчанию: сеанс без активности может считаться спящим примерно через 20 минут, а завершаться — ориентировочно через сутки. Эти значения администратор может менять, поэтому точные цифры на конкретном сервере нужно смотреть в консоли кластера, а не полагаться на умолчания.

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

Как проверить, сколько живут сеансы на вашем сервере

Откройте консоль администрирования серверов 1С, выберите кластер и посмотрите список сеансов по нужной информационной базе. Сеансы COM-подключений отображаются с типом приложения «COM-соединение» (COMConnection). Для каждого сеанса видны время начала, время последней активности и потребляемая память.

Практический тест: установите соединение из внешней программы, ничего не выполняйте и наблюдайте за сеансом в консоли. Зафиксируйте, через какое время он переходит в спящее состояние и когда исчезает из списка. Это и есть реальное время жизни неактивного соединения в вашей инфраструктуре.

1. 1
   Откройте консоль кластера и список сеансов нужной базы
2. 2
   Установите COM-соединение из внешней программы и зафиксируйте время
3. 3
   Наблюдайте за колонкой «Время последней активности» и статусом сеанса
4. 4
   Дождитесь перехода сеанса в спящий режим и его завершения, запишите интервалы
5. 5
   Сопоставьте замеры со свойствами кластера и при необходимости скорректируйте тайм-ауты

Как правильно закрывать COM-соединение

Единственный надёжный способ завершить сеанс — освободить все ссылки на COM-объект в клиентском коде. В 1С-коде это делается присваиванием переменной значения Неопределено; в скриптах на VBScript/JScript — установкой переменной в Nothing/null; в .NET — вызовом Marshal.ReleaseComObject или Marshal.FinalReleaseComObject.

Важно освобождать не только сам коннектор, но и все объекты, полученные через соединение: ссылки на объекты базы, результаты запросов, менеджеры объектов. Каждый такой объект держит внутреннюю ссылку на соединение, и пока он жив, сеанс не закроется — это самая частая причина «зависших» сеансов.

Соединение = Неопределено;
V83 = Новый COMОбъект("V83.COMConnector");
Попытка
    Соединение = V83.Connect(СтрокаПодключения);
    Результат = Соединение.Запросы.ВыполнитьВыборку();
Исключение
    Сообщить(ОписаниеОшибки());
КонецПопытки;
Соединение = Неопределено;
V83 = Неопределено;

Обратите внимание: простое завершение клиентского приложения не всегда мгновенно закрывает сеанс. Если процесс завершён аварийно, сервер узнает об обрыве только по тайм-ауту, и сеанс продолжит числиться активным до его срабатывания.

Повторное использование соединения вместо постоянного пересоздания

Установка COM-соединения — дорогая операция: создаётся сеанс, загружается конфигурация, проверяются права. Если внешняя программа обращается к базе часто, правильнее держать одно долгоживущее соединение и периодически выполнять через него лёгкие вызовы, чем создавать новое на каждую операцию.

Чтобы соединение не засыпало, используют «пинг» — простой вызов (например, получение текущей даты сервера или чтение константы) с интервалом меньше тайм-аута кластера. Это поддерживает сеанс активным. Однако бесконечно держать соединение тоже не стоит: при длительной работе в рабочем процессе накапливается память, поэтому полезна периодическая реинициализация — например, раз в несколько часов или при обнаружении ошибки.

Типичные ошибки и риски

Самая опасная ошибка — массовое создание соединений без закрытия в цикле или при каждом вызове веб-сервиса. Каждый такой сеанс занимает лицензию и память; при исчерпании лицензий пользователи не смогут войти в базу, а рабочий процесс сервера может упасть по памяти, уронив и обычные сеансы.

Вторая частая проблема — хранение COM-объекта в глобальной переменной или статическом поле службы Windows «на всякий случай» без контроля его состояния. После разрыва такой объект превращается в источник непонятных ошибок при каждом обращении, а диагностика усложняется тем, что сам объект формально существует.

Как проверить, что всё настроено правильно

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

Частые вопросы