Блокировка данных в 1С: зачем она нужна и как с ней работать

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

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

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

Что такое блокировка данных и зачем она нужна

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

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

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

Виды блокировок в платформе 1С

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

Автоматические блокировки

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

Управляемые блокировки

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

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

Сравнение режимов блокировок

Автоматические

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

Управляемые

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

Как блокировки проявляются для пользователя

Чаще всего пользователь сталкивается с блокировками через сообщения об ошибках. Характерные формулировки: «Конфликт блокировок при выполнении транзакции», «Превышено максимальное время ожидания предоставления блокировки», «Запись с такими ключевыми полями существует» (косвенный признак) и «Данные были изменены другим пользователем» при попытке сохранить объект.

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

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

Где возникают конфликты блокировок чаще всего

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

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

Третья причина — доработки. Написанный без учёта блокировок код (например, массовая обработка документов в одной длинной транзакции или чтение с последующей записью без управляемой блокировки) способен «положить» работу всего отдела.

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

Первый инструмент — технологический журнал. Включив события TLOCK, TDEADLOCK и TTIMEOUT, можно увидеть, какие сеансы, какие таблицы и какие диапазоны данных конфликтуют, и сколько длится ожидание. Это основной источник фактов для анализа.

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

Для глубокого анализа используются средства СУБД (например, динамические представления и отчёты по блокировкам в Microsoft SQL Server или PostgreSQL) и замеры производительности через механизм ЦУП или аналогичные инструменты мониторинга.

1. 1
   Зафиксируйте, в какой операции и у каких пользователей возникают ошибки
2. 2
   Проверьте список фоновых заданий: нет ли обменов и обработок в рабочее время
3. 3
   Включите технологический журнал с событиями TLOCK, TDEADLOCK, TTIMEOUT
4. 4
   Найдите в журнале пару конфликтующих сеансов и конкретные таблицы
5. 5
   Определите, чей код устанавливает проблемную блокировку: типовой или доработанный
6. 6
   Сократите длительность транзакций либо разнесите конфликтующие процессы по времени
7. 7
   Повторите проверку под нагрузкой и убедитесь, что ошибки исчезли

Как снизить число конфликтов: практические меры

Организационные меры часто дают эффект без всякой доработки кода. Регламентные задания (обмены, расчёты, загрузки) следует переносить на нерабочие часы или периоды минимальной активности. Массовые перепроведения и групповые обработки лучше запускать небольшими порциями, а не одной гигантской транзакцией.

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

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

Блокировки при разработке и доработке конфигураций

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

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

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

Часто задаваемые вопросы

Ошибка «Конфликт блокировок» — это опасно для данных?

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

Почему в файловой базе конфликты возникают чаще?

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

Можно ли вообще отключить блокировки, чтобы не мешали работать?

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

Что делать пользователю, который увидел сообщение о конфликте блокировок?

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

Что такое взаимоблокировка (deadlock)?

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

Влияют ли блокировки на скорость отчётов?

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