Конфликт блокировок при выполнении кода на сервере #752105

Есть код, в котором устанавливается управляемая блокировка на регистр бухгалтерии. Блокировка по регистратору. Этот код выполняется одновременно в двух сеансах на сервере, по разным регистраторам. При этом возникает конфликт блокировок, хотя они по разным значениям полей. Если же то же самое проделать в толстом клиенте, конфликт не возникает. Подскажите в чем может быть дело? База на MS SQL.

разделение итогов включено?

Включено

Кот покажи

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

1. ты же в одном сеансе заблокировал таблицу ИС_Бюджетирование, т.е. исключительная блокировка (уровень изоляции сериализабле) 2. а скорее всего во втором сеансе пробуешь прочитать из этой таблицы а эти блокировки несовместимы! по моему так!

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

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

в доках еще пишут что при уровне узоляции сериалазибле блокируются 2-е соседнии записи, т.е. сверху одна и снизу одна.

может запись в запросе именно туда попадает?

проверю

нет, этот вариант отпал. Походу я ошибся с выводами, протестил более внимательно еще несколько раз, и дело обстоит несколько иначе. Различий при выполнении на сервере и в толстом клиенте вроде бы нет. Но если делать как я описывал выше, поставив точку останова для "паузы" блокировки перед ЗафиксироватьТранзакцию, либо в любом месте цикла, и запустить во втором сеансе тот же код с другими регистраторами, то конфликта блокировок НЕ возникает. Если же просто сразу друг за другом стартануть в двух сеансах этот код (по разным регистраторам естественно), то возникает конфликт, ошибка выскакивает на строчке записи набора. Сам по себе каждый сеанс по отдельности отрабатывает за 40-50 секунд, если они друг другу не мешают. Ломаю голову.

У регистратора в метаданных блокировка тоже должна стоять управляемая, и у корня метаданных, по-моему, тоже

А что 1С-ка пишет, какая ошибка, скрин выложи!?

У корня стоит управляемая, у регистраторов тех, ко которым блокировка - тоже стоит управляемая. Вот ошибка: {ОбщийМодуль.МодульРегламентныхЗаданий.Модуль(2756)}: Ошибка при вызове метода контекста (Записать)                 Набор.Записать; по причине: Конфликт блокировок при выполнении транзакции: Microsoft SQL Server Native Client 11.0: Транзакция (идентификатор процесса 96) вызвала взаимоблокировку ресурсов блокировка с другим процессом и стала жертвой взаимоблокировки. Запустите транзакцию повторно.

Ошибка явно на MSSQL т.е. ошибка не на управляемых блокировках, не на сервере 1С ты как бы устанавливаешь управляемую блокировку на сервере 1С, а ошибка возникает на MSSQL у тебя точно управляемые режим включен на конфу? если бы была ошибка на управляемых блокировках тебе бы выдавалось предупреждение на русском от сервера 1С Предприятия! через профайлер пробовал разбираться? попробуй установи фильтр по дюрейшен >=2секунды, базе, ну и там SQL тексту запроса...

попробуй НачатьТранзакцию и Заблокировать перенести перед Запрос.Выполнить ну для того чтобы понять что не так!

deadlock на стороне СУБД. Скорее всего документы в выборке пересекаются в 2 сессиях.

И их нет в РС Бухгалтерии.

Документы точно не пересекаются, уже много раз проверял. Планирую сейчас провести тест: зарегистрирую ту же базу сервера SQL в новой базе сервера 1С, и запущу один сеанс с из старой базы, а один из новой. Если конфликт блокировок возникнет, значит проблема SQL-ная, иначе - СУБД.

"проблема SQL-ная, иначе - СУБД" - а в чем разница?

описался) проделал эксперимент из - похоже действительно ошибка на стороне MSSQL

кстати объект Блокировка тут не нужна, ибо набор записей сам все блокирует как надо

изначально и не делал, не работало все равно, это уже добавил в процессе танцев с бубнами Сейчас может попробуем с помощью гилёвского сервиса чего-нибудь посмотреть

просто отчистка регистра в потоках?

да, пытаюсь многопоточно очистить регистр

Перед очисткой предлагаю временно отключить итоги в регистре

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

при записи регистра случайно никаких процедур нет?

это еще не приходило в голову, пошел проверять!

Ибо взимоблокировки на 1 ресурсе - это блокировки повышения уровня блокировки, но тут чтения то нет совсем

Еще может быть это вообще блокировка не по регистру бухгалтерии. Есть последовательность, зависящая от данного регистра, там много кода выполняется при записи, буду проверять

Хотя тогда ошибка вываливалась бы на конкретной строчке обработчика (будь то в модуле набора записей регистра, процедуре на подписке и т.п.), а она вываливается именно на строчке Набор.Записать. Все равно попробую когда реструктуризация закончится (решил попробовать с отключенным разделением итогов).

Подключил к сервису Гилёва и выяснил, что взаимоблокировка возникает по таблице регистр бухгалтерии - субконто 1

а так же и по другим субконто

Контроль остатков?

Просто очищаются наборы записей по разным регистраторам в 2 потока. Никакого другого кода при этом (фоновые задания, подписки т.п.) не выполняется.

Даже скажу точнее, согласно сервису Гилева, взаимоблокировка действительно возникает между двумя потоками, когда в каждом из них выполняется одна и та же строка - Набор.Записать. Это тоже подтвержает что какой-либо внешний код (фоновое задание например какое-нибудь) тут непричем.

При записи набор записей РБ, в скуле взаимоблокировка возникает при пересечении по каким полям? При условии что совпадают измерения, то при совпадении любой из комбинаций Счет + Субконто1, Счет + Субконто1 + Субконто2, Счет + Субконто1 + Субконто2 + Субконто3, вроде бы так? Тогда получается достаточно чтобы не конфликтовало по комбинации Счет + Субконто1 + измерерния, так?

А для чего вам именно "РежимБлокировкиДанных.Исключительный" исключительная блокировка? А ты пробовал раздельную? И что тогда пишет? ...Данные так и так будут на момент проведения транзакции липовыми, коль вы в транзакции очищаете регистр... Да и бухгалтера в основном работают с данными за вчера. :)

Я восновном пробую вообще без управляемой блокировки, т.к. ошибка то в конфликте блокировок SQL.

Тут взаимоблокировка вида X(P1) > S(P1+P2) X(P2) > S(P1+P2) смотри где у тебя чтение идет

Чтения нигде нет

а запись чего-нибудь другого?

последовательность кстати автоматом двигается?

Щас вообще ее отключил, точнее исключил данный регистр из списка регистров от которых зависит последовательность. Вот сервис Гилёва конкретно показывает строчки кода в обоих процессах, при выполнении которых возникла взаимоблокировка - в обоих процессах это Набор.Записать

Можешь логин-пароль сказать к сервису?

Не дозволено) Могу скрины сделать интересующего

граф взаимоблокировки выложи

T1._Period, T1._AccountRRef, T1._Fld5629RRef, T1._Fld5630RRef, T1._Fld5631RRef, T1._Fld7041RRef, T1._Fld8081RRef, T1._Value1_TYPE, T1._Value1_L, T1._Value1_S, T1._Value1_RTRef, T1._Value1_RRRef, T1._Value2_TYPE, T1._Value2_L, T1._Value2_S, T1._Value2_RTRef, (@P1 numeric,@P2 numeric)INSERT INTO dbo._AccRgAT35657 (_Period, _AccountRRef, _Fld5629RRef, _Fld5630RRef, _Fld5631RRef, _Fld7041RRef, _Fld8081RRef, _Value1_TYPE, _Value1_L, _Value1_S, _Value1_RTRef, _Value1_RRRef, _Value2_TYPE, _Value2_L, _Value2_S, _Value2_RTRef, _Value2_RRRef, _Value3_TYPE, _Value3_L, _Value3_S, _Value3_RTRef, _Value3_RRRef, _Fld5633, _TurnoverDt5646, _TurnoverCt5647, _Turnover5648, _Fld5634, _TurnoverDt5649, _TurnoverCt5650, _Turnover5651, _Fld5632, _TurnoverDt5643, _TurnoverCt5644, _Turnover5645, _Fld5635, _TurnoverDt5652, _TurnoverCt5653, _Turnover5654, _Fld7683, _TurnoverDt7686, _TurnoverCt7687, _Turnover7688, _Fld7684, _TurnoverDt7689, _TurnoverCt7690, _Turnover7691, _Fld7685, _TurnoverDt7692, _TurnoverCt7693, _Turnover7694, _Splitter) SELECT T1._Period, T1._AccountRRef, T1._Fld5629RRef, T1._Fld5630RRef, T1._Fld5631RRef, T1._Fld7041RRef, T1._Fld8081RRef, T1._Value1_TYPE, T1._Value1_L, T1._Value1_S, T1._Value1_RTRef, T1._Value1_RRRef, T1._Value2_TYPE, T1._Period, T1._AccountRRef, T1._Fld5629RRef, T1._Fld5630RRef, T1._Fld5631RRef, T1._Fld7041RRef, T1._Fld8081RRef, T1._Value1_TYPE, T1._Value1_L, T1._Value1_S, T1._Value1_RTRef, T1._Value1_RRRef, T1._Value2_TYPE, T1._Value2_L, T1._Value2_S, T1._Value2_RTRef, (@P1 numeric,@P2 numeric)INSERT INTO dbo._AccRgAT35657 (_Period, _AccountRRef, _Fld5629RRef, _Fld5630RRef, _Fld5631RRef, _Fld7041RRef, _Fld8081RRef, _Value1_TYPE, _Value1_L, _Value1_S, _Value1_RTRef, _Value1_RRRef, _Value2_TYPE, _Value2_L, _Value2_S, _Value2_RTRef, _Value2_RRRef, _Value3_TYPE, _Value3_L, _Value3_S, _Value3_RTRef, _Value3_RRRef, _Fld5633, _TurnoverDt5646, _TurnoverCt5647, _Turnover5648, _Fld5634, _TurnoverDt5649, _TurnoverCt5650, _Turnover5651, _Fld5632, _TurnoverDt5643, _TurnoverCt5644, _Turnover5645, _Fld5635, _TurnoverDt5652, _TurnoverCt5653, _Turnover5654, _Fld7683, _TurnoverDt7686, _TurnoverCt7687, _Turnover7688, _Fld7684, _TurnoverDt7689, _TurnoverCt7690, _Turnover7691, _Fld7685, _TurnoverDt7692, _TurnoverCt7693, _Turnover7694, _Splitter) SELECT T1._Period, T1._AccountRRef, T1._Fld5629RRef, T1._Fld5630RRef, T1._Fld5631RRef, T1._Fld7041RRef, T1._Fld8081RRef, T1._Value1_TYPE, T1._Value1_L, T1._Value1_S, T1._Value1_RTRef, T1._Value1_RRRef, T1._Value2_TYPE,