В мире работы с системами 1С существует проблема, способная всерьез осложнить жизнь разработчикам – взаимоблокировки 1C (DEADLOCKS). Это не просто ошибки, а настоящие «патовые» ситуации, когда несколько сессий напрочь блокируют друг друга, останавливая бизнес-процессы. Если ваши пользователи начали жаловаться на внезапные отказы системы с сообщениями о взаимоблокировках, а вы хотите не просто перезапустить процесс, а разобраться в корне проблемы – эта статья для вас.
Что такое взаимоблокировка 1С?
Простыми словами, взаимоблокировка – это тупиковая ситуация, в которую попадают две или более транзакций. Простая аналогия: Два автомобиля встретились на узком мосту. Чтобы проехать, первому нужно, чтобы второй сдал назад, и наоборот. Ни один из них не может двигаться, возникает безвыходная ситуация.
Технически это выглядит так:
- Сессия 1 заблокировала ресурс А и ждет, когда освободится ресурс Б.
- Сессия 2 в это же время заблокировала ресурс Б и ждет, когда освободится ресурс А.
Ни одна из сессий не может продолжить работу, так как каждая удерживает то, что нужно другой. Разрулить этот конфликт может только специальный механизм – «менеджер блокировок», встроенный в СУБД или в сам сервер 1С:Предприятия. Он с определенной периодичностью проверяет систему на наличие таких тупиков и, обнаружив их, приносит одну из транзакций в «жертву». Транзакция-жертва откатывается, все ее блокировки снимаются, а конкурирующие сессии получают возможность продолжить работу. Пользователь, чья транзакция была выбрана «жертвой», видит сообщение об ошибке.
Важно понимать: одна и та же ошибка в коде может порождать разные по сложности взаимоблокировки. Поэтому начинать анализ всегда стоит с самых простых случаев – с минимальным количеством участников. Устранив одну простую причину, вы можете разом избавиться от целого ряда более сложных инцидентов.
Основные причины взаимоблокировок и как их устранить
Существует четыре основные причины возникновения взаимоблокировок. Мы разберем две самые распространенные, имеющие максимальное практическое значение.
1. Повышение уровня блокировки ресурса в рамках одной транзакции
Это самая частая причина взаимоблокировок. Ее суть в том, что в рамках одной транзакции один и тот же ресурс (например, остатки по конкретному товару на складе) сначала читается, а затем изменяется.
Как это происходит:
- Транзакция 1 и Транзакция 2 одновременно считывают остатки по товару Х. При этом СУБД устанавливает разделяемые блокировки (S – Shared). Они не мешают друг другу, так как данные можно читать параллельно.
- Транзакция 1 пытается записать изменения в остатки по товару Х. Для этого ей нужна эксклюзивная блокировка (X – eXclusive). Но она не может быть установлена, пока на ресурсе висит разделяемая блокировка от Транзакции 2. Транзакция 1 встает в очередь и ждет.
- Транзакция 2 также пытается записать изменения в тот же товар Х и тоже запрашивает эксклюзивную блокировку. Но этому мешает разделяемая блокировка Транзакции 1.
Результат: взаимоблокировка. Каждая транзакция ждет, пока другая освободит ресурс, но ни одна не может этого сделать, не завершив свою работу.
Решение: Блокировка в транзакции должна изначально осуществляться с максимально необходимым уровнем изоляции. Если вы планируете данные не только читать, но и изменять, блокируйте их на запись сразу.
2. Захват ресурсов в разном порядке
Вторая по распространенности причина. Здесь конфликт возникает не вокруг одного ресурса, а вокруг нескольких, которые транзакции захватывают в разной последовательности.
Как это происходит:
- Транзакция 1 блокирует ресурс А, а затем пытается заблокировать ресурс Б.
- Транзакция 2 блокирует ресурс Б, а затем пытается заблокировать ресурс А.
Результат: Транзакция 1 ждет, пока Транзакция 2 освободит Б, а Транзакция 2 ждет, пока Транзакция 1 освободит А. Снова патовую ситуацию разрешает менеджер взаимоблокировок.
Решение: Ресурсы в транзакции должны блокироваться в одинаковом порядке.
3. Ошибка блокировок 1С при работе внутренних механизмов СУБД
Распараллеливание процессов
СУБД может самостоятельно распределять выполнение операций между различными процессорами системы. Если несколько процессов, работающих на разных ядрах, одновременно блокируют одни и те же ресурсы, возникает взаимоблокировка.
Решение: Чтобы предотвратить подобные ситуации, необходимо заранее проверять возможность предоставления ресурса. По умолчанию параметр “max degree of parallelism” в СУБД установлен в значение 0, что разрешает использование всех процессоров. Установка этого параметра в значение 1 ограничивает параллельное выполнение и снижает вероятность взаимоблокировок.
Поиск причин взаимоблокировок при работе с технологическим журналом
Основной инструмент для расследования причин возникновения взаимоблокировок – технологический журнал 1С. Для того чтобы собрать необходимые логи, нужно настроить конфигурационный файл технологического журнала – logcfg.xml:
Пример настройки:
<?xml version="1.0" encoding="UTF-8"?> <config xmlns="http://v8.1c.ru/v8/tech-log"> <log location="C:\Logs\LOCKS" history="24"> <event> <eq property="name" value="TLOCK"/> </event> <event> <eq property="name" value="TTIMEOUT"/> </event> <event> <eq property="name" value="TDEADLOCK"/> </event> <event> <eq property="name" value="DBMSSQL"/> </event> <event> <eq property="Name" value="SDBL"/> <eq property="Func" value="BeginTransaction"/> </event> <property name="all"/> </log> </config>
Рассмотрим записи технологического журнала на примере одной блокировки:
Событие TDEADLOCK
42:43.879010-0,TDEADLOCK,6,level=INFO,process=rphost,p:processName=LOCKS,OSThread=1652,t:clientID=77,t: applicationName=1CV8C,t:computerName=pcName,t:connectID=35,SessionID=27,Usr=Администратор, AppID=1CV8C,DBMS=DBMSSQL,DataBase=localhost\LOCKS,DeadlockConnectionIntersections= ’35 1 InfoRg40.DIMS Exclusive Fld41=”ПолеА” Fld42=”ПолеБ”,1 35 InfoRg40.DIMS Exclusive Fld41=”ПолеА” Fld42=”ПолеБ”‘,Context=’Форма.Вызов : Обработка.Блокировки.Форма.Форма.Модуль.ТестБлокировки Обработка.Блокировки.Форма.Форма.Форма : 404 : НаборЗаписей.Записать();’
Жертва
42:33.864003-3,TLOCK,5,level=INFO,process=rphost,p:processName=LOCKS,OSThread=1652,t:clientID=77,t: applicationName=1CV8C,t:computerName=pcName,t:connectID=35,SessionID=27,Usr=Администратор, AppID=1CV8C,DBMS=DBMSSQL,DataBase=localhost\LOCKS,Regions=InfoRg40.DIMS,Locks= ‘InfoRg40.DIMS Shared Fld41=”ПолеА” Fld42=”ПолеБ”‘,WaitConnections=,Context=’Форма.Вызов : Обработка.Блокировки.Форма.Форма.Модуль.ТестБлокировки Обработка.Блокировки.Форма.Форма.Форма : 402 : НаборЗаписей.Прочитать();’
42:43.895001-15995,TLOCK,5,level=INFO,process=rphost,p:processName=LOCKS,OSThread=1652,t:clientID=77,t: applicationName=1CV8C,t:computerName=pcName,t:connectID=35,SessionID=27,Usr=Администратор, AppID=1CV8C,DBMS=DBMSSQL,DataBase=localhost\LOCKS,Regions=InfoRg40.DIMS,Locks= ‘InfoRg40.DIMS Exclusive Fld41=”ПолеА” Fld42=”ПолеБ”‘,WaitConnections=1,Context=’Форма.Вызов : Обработка.Блокировки.Форма.Форма.Модуль.ТестБлокировки Обработка.Блокировки.Форма.Форма.Форма : 404 : НаборЗаписей.Записать();’
Виновник
42:41.129018-3,TLOCK,4,level=INFO,process=rphost,p:processName=LOCKS,OSThread=2020,t:clientID=18,t: applicationName=1CV8C,t:computerName=pcName,t:connectID=1,SessionID=1,Usr=Администратор, AppID=1CV8C,DBMS=DBMSSQL,DataBase=localhost\LOCKS,Regions=InfoRg40.DIMS,Locks= ‘InfoRg40.DIMS Shared Fld41=”ПолеА” Fld42=”ПолеБ”‘,WaitConnections=,Context=’Форма.Вызов : Обработка.Блокировки.Форма.Форма.Модуль.ТестБлокировки Обработка.Блокировки.Форма.Форма.Форма : 402 : НаборЗаписей.Прочитать();’
42:43.911017-2781994,TLOCK,4,level=INFO,process=rphost,p:processName=LOCKS,OSThread=2020,t:clientID=18,t: applicationName=1CV8C,t:computerName=pcName,t:connectID=1,SessionID=1,Usr=Администратор, AppID=1CV8C,DBMS=DBMSSQL,DataBase=localhost\LOCKS,Regions=InfoRg40.DIMS,Locks= ‘InfoRg40.DIMS Exclusive Fld41=”ПолеА” Fld42=”ПолеБ”‘,WaitConnections=35,connectionID=5dec9403-e945-4cfc-a297-70b26819d95f,Context=’Форма.Вызов : Обработка.Блокировки.Форма.Форма.Модуль.ТестБлокировки Обработка.Блокировки.Форма.Форма.Форма : 404 : НаборЗаписей.Записать();’
Разберем, что же здесь написано:
Первое событие TLOCK у жертвы и виновника накладывает разделяемую (S) блокировку на объект InfoRg40 (Regions=InfoRg40) на следующие поля:
Shared Fld41=”ПолеА” Fld42=”ПолеБ”
Так как блокировка разделяемая, конфликтов на этом этапе пока нет. После чего, исходя из второй записи события TLOCK у жертвы и виновника, возникает необходимость изменения данных, и для этого осуществляется попытка установки исключаемой (X) блокировки:
Exclusive Fld41=”ПолеА” Fld42=”ПолеБ”
Но так как разделяемая и исключительная блокировки не совместимы между собой, попытки установки исключительной блокировки становятся в очередь, где попытка установки исключительной блокировки виновником ожидает снятия разделяемой блокировки жертвы, а попытка установки исключительной блокировки жертвой ожидает снятия разделяемой блокировки виновника. В итоге мы получаем ситуацию, когда обе транзакции ожидают снятия блокировки друг друга, но этого не происходит. В таком случае появляется запись события TDEADLOCK, где указан connectId жертвы и виновника, а также объект блокировки:
DeadlockConnectionIntersections=’35 1 InfoRg40
Где 1 – connectID виновника, а 35 – connectID жертвы.
Транзакция жертвы в таком случае откатывается и пользователь получает сообщение об ошибке блокировок.
Решение такой взаимоблокировки было описано выше:
Блокировка в транзакции должна изначально осуществляться с максимально необходимым уровнем изоляции. Если вы планируете данные не только читать, но и изменять, блокируйте их на запись сразу.
Заключение
Взаимоблокировки 1C – это не просто случайные сбои или «баги» в работе системы, а следствие архитектурных просчетов в проектировании и реализации прикладной логики. Их появление свидетельствует о нарушении принципов согласованного доступа к данным и некорректной организации транзакционной модели.
Важно понимать, что оправданных взаимоблокировок не существует – их наличие всегда указывает на ошибку в коде или проектных решениях. Для предотвращения подобных ситуаций необходимо изначально проектировать логику работы с данными с учетом ключевых факторов риска.
Таким образом, борьба с взаимоблокировками – это не устранение частных ошибок, а системная работа по повышению качества архитектуры решения, обеспечению стабильности транзакционных процессов и предсказуемости поведения системы под нагрузкой.
Для эффективного поиска и анализа взаимоблокировок 1С можно использовать различные инструменты, например как Metrika42 – мониторинг производительности 1С. Этот продукт предоставляет функционал для сбора и анализа логов блокировок, что помогает выявить причины взаимоблокировок и предотвратить их возникновение в будущем.
