Блокировки данных в 1С: как работают и как управлять ими

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

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

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

Какие виды блокировок существуют в 1С

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

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

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

Автоматический и управляемый режимы: в чём разница

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

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

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

Сравнение вариантов

Автоматический режим

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

Управляемый режим

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

Смешанный режим

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

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

Управляемая блокировка устанавливается программно до начала изменения данных. Разработчик создаёт объект БлокировкаДанных, добавляет в него элементы с указанием пространства блокировок (например, «РегистрНакопления.ТоварыНаСкладах») и задаёт диапазон значений измерений — конкретный склад, номенклатуру или список товаров. Затем вызывается метод Заблокировать() внутри транзакции.

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

1. 1
   Начните транзакцию методом НачатьТранзакцию()
2. 2
   Создайте объект БлокировкаДанных и добавьте элемент для нужного пространства блокировок
3. 3
   Задайте диапазон: конкретное значение измерения или источник данных с отбором
4. 4
   Вызовите метод Заблокировать() — при конфликте будет вызвано исключение
5. 5
   Прочитайте данные, выполните изменения и зафиксируйте транзакцию
6. 6
   Убедитесь, что в коде нет веток, где транзакция остаётся незавершённой

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

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

Конфликт блокировок возникает, когда сеанс пытается установить блокировку на данные, уже заблокированные другим сеансом в несовместимом режиме. СУБД либо заставляет сеанс ждать (по умолчанию ожидание ограничено настройкой тайм-аута), либо сразу возвращает ошибку, если ожидание отключено. Типичные источники конфликтов: длительные транзакции, массовые перепроведения документов, обмены данными в рабочее время, регламентные задания, пересекающиеся с активностью пользователей.

Взаимоблокировка — более коварный случай. Классический сценарий: первый сеанс заблокировал товар А и хочет заблокировать товар Б, второй сеанс заблокировал товар Б и хочет товар А. Оба ждут бесконечно, поэтому СУБД выбирает «жертву» и откатывает одну из транзакций с ошибкой. Пользователь видит сообщение о взаимоблокировке и вынужден повторить операцию.

Главная причина взаимоблокировок в прикладном коде — разный порядок обращения к данным в разных процедурах. Если один документ при проведении сначала пишет регистр «Остатки», потом «Резервы», а другой — наоборот, при параллельной работе взаимоблокировки практически гарантированы. Стандартное решение — единый регламентированный порядок обращения к регистрам и сортировка наборов данных перед блокировкой.

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

Основной инструмент диагностики — технологический журнал сервера 1С с включёнными событиями TLOCK, TDEADLOCK, TTIMEOUT и DBMSSQL (или аналогом для используемой СУБД). По событиям TDEADLOCK видно, какие запросы и в каком порядке обращались к данным, что позволяет найти конфликтующие процедуры.

Дополнительно используются средства самой СУБД: в MS SQL Server — системные представления sys.dm_tran_locks и sys.dm_exec_requests, показывающие, кто кого блокирует в текущий момент; в PostgreSQL — представление pg_locks в связке с pg_stat_activity. В консоли кластера 1С можно увидеть активные сеансы и соединения, что помогает связать блокировку СУБД с конкретным пользователем.

Контрольные точки

Как проверить результат

Журнал регистрации и технологический журнал

Норма

Ошибки TDEADLOCK и TTIMEOUT отсутствуют или единичны в часы пик

Тревожный признак

Регулярные взаимоблокировки в одно и то же время или на одних документах

Длительность транзакций

Норма

Проведение документа занимает секунды, транзакции короткие

Тревожный признак

Транзакции висят десятки секунд и минут, удерживая блокировки

Режим блокировок конфигурации

Норма

Управляемый режим, в коде блокировки ставятся до чтения данных

Тревожный признак

Автоматический режим при большом числе пользователей, блокировки после чтения

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

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

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

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

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

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

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

Что делать пользователю при ошибке «Объект уже заблокирован»?

Это объектная блокировка: кто-то редактирует тот же документ или элемент справочника. Обычно достаточно подождать и повторить попытку. Если блокировка «висит», а владелец объекта давно вышел, администратор может завершить зависший сеанс через консоль кластера серверов 1С.

Можно ли полностью отключить блокировки, чтобы не было ошибок?

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

Почему ошибка «Конфликт блокировок» возникает только в определённое время?

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

Обязательно ли переводить конфигурацию в управляемый режим блокировок?

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

Как понять, кто именно держит блокировку прямо сейчас?

В консоли кластера 1С посмотрите активные сеансы и соединения, а на стороне СУБД — текущие блокировки через системные представления (в MS SQL Server — sys.dm_tran_locks). Сопоставив идентификатор соединения, можно определить конкретного пользователя и выполняемый им запрос.

Помогает ли увеличение мощности сервера при конфликтах блокировок?

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