Управляемые блокировки в 1С: суть, настройка и практика

Управляемая блокировка в 1С — это механизм платформы, который позволяет разработчику самостоятельно контролировать конкурентный доступ к данным при параллельной работе пользователей и фоновых заданий. В отличие от автоматических блокировок, которые платформа устанавливает по своим внутренним правилам, управляемые блокировки задаются явно в коде: программист указывает, какой объект данных, какое пространство блокировки и какой режим (разделяемый или исключительный) требуется. Такой подход даёт более тонкий контроль и позволяет избежать избыточного захвата данных, который тормозит работу базы при высокой нагрузке.

Механизм особенно важен в клиент-серверном варианте работы, где десятки и сотни сеансов одновременно проводят документы, изменяют регистры и читают справочники. Без грамотного управления блокировками возникают конфликты: один сеанс ждёт освобождения ресурса, захваченного другим, время ожидания истекает, и пользователь получает ошибку «Конфликт блокировок при выполнении транзакции». Понимание того, как устроены управляемые блокировки, помогает и разработчику писать устойчивый код, и администратору правильно диагностировать проблемы производительности.

Чем управляемые блокировки отличаются от автоматических

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

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

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

Как включить управляемый режим в конфигурации

Режим блокировок настраивается в конфигураторе. Откройте свойства корневого узла конфигурации и найдите свойство «Режим управления блокировкой данных». Доступны три значения: «Автоматический», «Управляемый» и «Автоматический и управляемый». Третий вариант означает, что для конфигурации в целом действует управляемый режим, но для конкретных объектов (документов, регистров) можно задать автоматический через одноимённое свойство объекта метаданных.

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

Как программно установить управляемую блокировку

Программная установка блокировки выполняется через объект БлокировкаДанных. Типовой шаблон выглядит так: создаётся объект блокировки, добавляется элемент блокировки для нужного пространства (например, «РегистрНакопления.ОстаткиТоваров»), устанавливается режим — РежимБлокировкиДанных.Исключительный или Разделяемый, задаётся отбор по полям, затем вызывается метод Заблокировать(). Блокировка действует до конца транзакции, поэтому весь фрагмент должен быть обёрнут в НачатьТранзакцию() … ЗафиксироватьТранзакцию().

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

НачатьТранзакцию();
Блокировка = Новый БлокировкаДанных;
Элемент = Блокировка.Добавить("РегистрНакопления.ОстаткиТоваров");
Элемент.Режим = РежимБлокировкиДанных.Исключительный;
Элемент.УстановитьЗначение("Номенклатура", Товар);
Элемент.УстановитьЗначение("Склад", Склад);
Блокировка.Заблокировать();
// далее чтение остатков и запись движений
ЗафиксироватьТранзакцию();

Разделяемый и исключительный режимы: что выбрать

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

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

Типичные конфликты и взаимоблокировки

Взаимоблокировка (deadlock) возникает, когда две транзакции захватили разные ресурсы и каждая ждёт освобождения ресурса другой. Классический сценарий: транзакция А заблокировала товар 1 и ждёт товар 2, транзакция Б заблокировала товар 2 и ждёт товар 1. Платформа обнаруживает такую ситуацию и принудительно завершает одну из транзакций с ошибкой.

Главная профилактика — единый порядок блокирования ресурсов во всём коде конфигурации. Если все процедуры блокируют сначала контрагента, потом договор, потом документ, циклическое ожидание невозможно. Дополнительно помогает сортировка блокируемых значений (например, список товаров блокируется в порядке возрастания ссылок) и сокращение времени жизни транзакций: чем короче транзакция, тем меньше окно для конфликта.

Как диагностировать проблемы с блокировками

Основные инструменты диагностики — технологический журнал и консоль кластера серверов 1С. В технологическом журнале события TLOCK, TDEADLOCK и TTIMEOUT показывают, какие блокировки устанавливались, где возникли взаимоблокировки и превышения времени ожидания. В консоли кластера видны текущие сеансы и их блокировки, что позволяет найти «зависший» сеанс, удерживающий ресурс.

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

Когда обращаться к специалисту

Самостоятельная работа с блокировками оправдана, если вы понимаете транзакционную модель и имеете тестовую копию базы. Установка блокировки в простом сценарии — списание остатка по одному товару — доступна начинающему разработчику по шаблону из этой статьи. Но перевод целой конфигурации на управляемый режим, разбор хронических взаимоблокировок в высоконагруженной системе и оптимизация критичных участков проведения требуют опыта анализа технологического журнала и планов запросов СУБД.

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

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