← На главную

При увеличении количества мобильных устройств, синхронизирующихся с центральной информационной базой 1С через веб-сервисы и планы обмена, разработчики часто сталкиваются с критической ситуацией. Когда несколько десятков или сотен устройств одновременно вызывают сервис синхронизации раз в 5–10 минут, транзакции начинают падать с ошибкой «Конфликт блокировок при выполнении транзакции». На стороне мобильного клиента при этом может возникать аварийное завершение с блокировкой таблицы config. Разберем детально природу этих блокировок и рассмотрим практические способы решения проблемы.

Почему возникают блокировки в центральной базе

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

Выясним причину конфликта на сервере СУБД:

1. Эскалация блокировок (Lock Escalation): на физическом уровне таблицы изменений содержат измерения, указывающие на конкретный узел. При одновременном обращении нескольких мобильных узлов СУБД (например, MS SQL Server или PostgreSQL) блокирует не только отдельные строки, но и целые страницы или таблицу изменений целиком. В результате процесс чтения одного мобильного устройства блокирует попытки чтения или регистрации данных для остальных.
2. Встречные транзакции бизнес-логики: если в центральной базе включена авторегистрация объектов, любая запись документа или справочника пользователями центральной базы накладывает блокировку на добавление записей в таблицы изменений. Попытка мобильного клиента выгрузить данные в этот момент мгновенно приводит к таймауту ожидания блокировки.
3. Длительное удержание транзакции: если формирование пакета изменений, его сериализация в XML/JSON и передача по сети выполняются внутри одной неделимой транзакции, таблица изменений остается монопольно захваченной в течение всего сетевого обмена.

Причина ошибки «Не удалось заблокировать таблицу config» на мобильном клиенте

Рассмотрим, откуда берется ошибка блокировки таблицы config в мобильном приложении. Локальная база мобильной платформы 1С работает под управлением встраиваемой СУБД SQLite. Архитектура SQLite устроена так, что в один момент времени писать в базу данных может только один поток.

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

Решение 1. Оптимизация транзакционной логики и изоляция сетевых вызовов

Разберем по шагам, как правильно разделить операции на сервере и мобильном устройстве, чтобы минимизировать время захвата блокировок.

На мобильном устройстве категорически запрещено выполнять вызовы сетевых сервисов внутри транзакций локальной базы. Посмотрим на правильный порядок реализации:

1. В короткой локальной транзакции считываем подготовленные для отправки данные в оперативную память.
2. Завершаем транзакцию на мобильном устройстве (ЗафиксироватьТранзакцию()).
3. Вызываем веб-сервис или HTTP-сервис центральной базы вне транзакции и дожидаемся ответа.
4. Получив пакет ответа в память, открываем новую короткую транзакцию исключительно для быстрой записи принятых объектов в локальную базу данных.

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

Решение 2. Асинхронная подготовка пакетов выгрузки регламентным заданием

Рассмотрим архитектурный подход, полностью устраняющий конкуренцию мобильных клиентов за таблицу плана обмена при чтении. Вместо динамического формирования пакета в момент входящего вызова от мобильного устройства, центральная база готовит данные заранее в фоновом режиме.

Схема реализации выглядит следующим образом:

1. В центральной базе создаем регистр сведений, например, ОчередьПакетовОбмена с измерениями УзелОбмена и ресурсом типа ХранилищеЗначения для сжатого пакета данных.
2. Регламентное задание центральной базы последовательно обходит активные узлы обмена, считывает изменения из плана обмена, формирует сериализованные пакеты и записывает их в регистр сведений. Сразу после этого зарегистрированные изменения для узла удаляются.
3. Когда мобильное устройство обращается к веб-сервису, метод веб-сервиса просто считывает готовый бинарный пакет из регистра сведений по конкретному узлу.

В этом сценарии мобильные устройства читают обычный регистр сведений по точному значению ключа записи, вообще не затрагивая системные таблицы регистрации изменений плана обмена.

Решение 3. Переход от опроса к Push-уведомлениям

Постоянный опрос базы (polling) сотней устройств раз в 5–10 минут создает колоссальный поток холостых вызовов. Если за 10 минут данных для конкретного мобильного устройства не появилось, обращение все равно создает нагрузку на веб-сервер и кратковременные блокировки.

Проанализируем правильную мобильную архитектуру на основе Push-уведомлений:

1. Мобильные устройства инициируют выгрузку только тогда, когда пользователь действительно создал новые локальные документы или записи.
2. Для доставки изменений из центра в мобильные устройства используется механизм push-уведомлений.
3. В узле обмена регистрируется идентификатор push-клиента.
4. Регламентное задание в центральной базе проверяет наличие зарегистрированных изменений. При появлении новых данных сервер отправляет push-сообщение мобильному клиенту.
5. Получив уведомление, мобильное приложение выполняет разовый регламентный забор сформированного для него пакета.

Решение 4. Перевод базы на управляемые блокировки и разделение планов обмена

Если в конфигурации центральной базы режим управления блокировкой данных установлен в значение «Автоматический», СУБД блокирует слишком широкие диапазоны записей. Переведем конфигурацию в «Управляемый» режим. Это заставит платформу управлять блокировками на уровне логических записей 1С, исключая взаимные зависания непересекающихся узлов.

Также проанализируем структуру передаваемых данных:

1. Разделение планов обмена: вынесите справочную нормативно-справочную информацию (НСИ) и оперативные документы в два независимых плана обмена. Это распределит конкуренцию по разным физическим таблицам СУБД.
2. Использование HTTP-сервисов: замените SOAP веб-сервисы на легковесные HTTP-сервисы с форматом передачи JSON. HTTP-сервисы работают с меньшими накладными расходами на сериализацию и снижают время удержания сетевого подключения к веб-серверу IIS или Apache.
3. Настройка веб-сервера: увеличьте лимиты пула подключений (MaxConcurrentRequests) и количество рабочих процессов в веб-сервере, чтобы предотвратить появление таймаутов на этапе установления сетевого соединения.