Когда снимается управляемая блокировка в 1С

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

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

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

Что такое управляемая блокировка и чем она отличается от автоматической

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

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

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

Основные ситуации снятия управляемой блокировки

Платформа освобождает заблокированные ресурсы строго в определённые моменты. Знание этого списка позволяет предсказать поведение системы и найти причину, если блокировка «не отпускает».

Фиксация транзакции

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

Откат транзакции

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

Явное снятие из кода

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

Завершение сеанса

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

1. 1
   Откройте консоль кластера и найдите сеанс, удерживающий блокировку, либо используйте функциональность «Управление блокировками» в типовых конфигурациях.
2. 2
   Определите, активна ли транзакция сеанса: длительная транзакция — легальная причина удержания.
3. 3
   Проверьте журнал регистрации и технологический журнал на события TLOCK и TDEADLOCK.
4. 4
   Если сеанс аварийно завис — завершите его штатно через консоль кластера.
5. 5
   После снятия проверьте, что ожидавшие пользователи смогли выполнить операцию.

Как узнать, что блокировка ещё удерживается

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

Администратор может увидеть картину целиком. В консоли кластера серверов 1С доступен список сеансов и соединений; в типовых конфигурациях на БСП есть обработка «Управление блокировками» (или аналогичный механизм в разделе администрирования), показывающая, какой сеанс что блокирует. Наиболее детальную информацию даёт технологический журнал с событиями TLOCK, TWAIT и TDEADLOCK.

Типичные причины, по которым блокировка не снимается вовремя

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

• Длительная транзакция. Внутри транзакции выполняется тяжёлый запрос, обмен данными или обращение к внешнему сервису. Блокировки законно удерживаются всё это время.
• Интерактивные действия в транзакции. Код ждёт ответа пользователя (вопрос, открытая форма) при открытой транзакции — блокировка висит, пока человек не нажмёт кнопку.
• Внетранзакционная блокировка без снятия. Разработчик установил блокировку вне транзакции и не предусмотрел вызов снятия на всех ветках кода, включая исключения.
• Аварийно зависший клиент. Тонкий клиент «замерз», но сеанс на сервере ещё жив, и его блокировки удерживаются до таймаута завершения сеанса.
• Взаимоблокировки (deadlock). Два сеанса захватили ресурсы в разном порядке; СУБД откатывает одну жертву, но у пользователя это выглядит как периодические «зависания».

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

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

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

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

Профилактика: как сократить время удержания блокировок

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

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

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

Маршрут решения

Как выбрать действие

Пользователь получил ошибку конфликта блокировок один разПовторите операцию — вероятно, ресурс был занят короткой транзакцией

Ошибки повторяются у разных пользователей на одних данныхНайдите сеанс-владельца блокировки и проверьте, активна ли его транзакция

Сеанс не отвечает, транзакция висит долгоЗавершите сеанс через консоль кластера и проверьте код на интерактивные вызовы в транзакции

В техножурнале регулярные TDEADLOCKПроанализируйте порядок установки блокировок в конфликтующих процедурах и унифицируйте его

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

Снимается ли управляемая блокировка по таймауту сама?

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

Что происходит с блокировками при обрыве связи клиента с сервером?

Сеанс некоторое время остаётся в кластере как «спящий» и его блокировки удерживаются. После истечения настроенного таймаута завершения сеанс удаляется, и все его блокировки освобождаются автоматически.

Можно ли снять чужую блокировку программно из кода?

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

Почему после отката транзакции пользователь всё равно видит ошибку блокировки?

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

Влияет ли режим совместимости конфигурации на снятие блокировок?

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

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

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