Управляемые блокировки. Конфликт блокировок при блокировках по разным полям. #759691

Вечер добрый! Наткнулся на следующую проблему. Одновременно выполняется 2 сеанса. Оба устанавливают управляемые блокировки по одному регистру сведений, но по разным полям, по конкретному значению. При этом один сеанс блокирует другой, хотя по логике этого быть не должно. Кто знает в чём дело? Пример кода сеанса 1. НачатьТранзакцию(РежимУправленияБлокировкойДанных.Управляемый); Пример кода сеанса 2. НачатьТранзакцию(РежимУправленияБлокировкойДанных.Управляемый);

Версия платформы 8.3.6. СУБД SQL.

Дело в твоем понимании работы блокировок. У тебя в записях с Измерение1="1" встречаются такие, где Измерение2 = "2"

Нет, проверял. Данные не пересекаются.

Может, транзакция открывается внутри другой транзакции (в т.ч. неявной), у которой режим блокировки автоматический?

Я бы не был так уверен

Ну и у свойства конфигурации "Режим управления блокировкой данных" выбрано какое значение&

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

Свойство установлено в Управляемый

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

а что на пустом регистре?

мне кажется блокировка по измерению1 = 1, блокирует по данному измерению и ПО ВСЕМ другим измерениям

Измерение 2 проиндексировано?

Оба проиндексированы.

Возможно вы правы. Я тоже об этом думаю. Но в документации ничего подобного не встречал.

На каком наборе данных тестировали? Измерение1 и Измерение2 Как разные Измерения одного и того же регистра. Почему вы так уверены, что при блокировки "Измерение1", то что вы не содержите значения по "Измерение2". Больше склонен думать, что все же дело в отражена суть. И в дан правильный ответ. И логичный. Нам тут трудно видеть, что у вас там на заведено :)

В частности на пустом наборе данных тестировал.

Я думаю, происходит эскалация блокировки, т.к. диапазон записей, которые попадают в блокировку при блокировании по одному измерению, приближается к общему кол-ву записей в таблице. В ТЖ, к сожалению, событие эксалации не пишется... Для эксперимента попробуй накидать в регистр много больше записей с измерениями "3" и "4" и проверь опять взаимоблокировку на "1" и "2"

Эскалация происходит не из-за большого кол-ва записей в таблице, а из-за количества самих блокировок на одно пространство. Цитата с документации: "Следует помнить, что если на одно пространство накладывается более 100 000 блокировок, то может произойти эскалация блокировки."

Упр блокировки не смотрят на индекс

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

Делаю вывод, о том как работают управляемые блокировки: 1) Управляемые блокировки не оперируют данными СУБД. Представьте, если бы в таблице были бы миллионы записей. Сколько бы времени уходило на установку блокировки. Даже если поля были бы проиндексированы. 2) При установке управляемой блокировки, в памяти какого-нибудь менеджера кластера сохраняются параметры этой самой блокировки. При этом проверяется, не установлена ли уже блокировка пересекающаяся с указанным диапазоном. Если установлена, то блокировка встаёт в очередь и ждёт. 3) Когда устанавливаются управляемые блокировки по различным полям, сервер не в состоянии однозначно определить, пересекаются они или нет, поэтому исходит из позиции, что они могут пересекаться. И соответственно ставит нашу блокировку в очередь.

Значит при проектировании системы, необходимо более детально устанавливать блокировки. Возможно вводить какие-нибудь ключевые измерения... Например есть 3 измерения: Изм1, Изм2, Изм3. Можно блокировать диапазон по Изм1. Если хотим по Изм2, то обязательно устанавливаем еще и Изм1. А если хотим еще и Изм3, то дополнительно указываем Изм1, Изм2.

Чет ваши выводы не утешительны... Сдается мне, что не стоит пренебрегать измерениями... ...Если лочите первое, то и лочте его везде :)

Думаю тему можно считать закрытой, если никто не хочет больше ничего добавить =)

Детализация тут ни при чем. Главное повторять блокировки :)

Ну если бы я придумывал эти управляемые блокировки, то  сделал бы так. =)

Все ровно спасибо... Приму во внимание :)

А для MS SQL актуальны ли управляемые блокировки? Я с ними манался при работе с Oracle. Там блокировка на уровне таблиц.

Да, дело не в детализации. Возможно надо было по другому выразиться. Пример с 3 измерениями лучше объясняет то , что я имел ввиду)

Актуальны, в случае когда нужна согласованность данных при одновременной работе пользователей.

Ахха... освежил свои знания насчет READ COMMITED, REPEATABLE READ и SERIALIZABLE . Сорри.

Например Васе и Пете нужно положить яблоко в коробку, а в коробке место только под одно яблоко =) Нужно блокировать эту коробку, чтобы одновременно они туда свои яблоки не положили =)

Щас у нас уже READ COMMITED SNAPSHOT. Благая вещь =)