Вечер добрый!

Наткнулся на следующую проблему.
Одновременно выполняется 2 сеанса. Оба устанавливают управляемые блокировки по одному регистру сведений, но по разным полям, по конкретному значению. При этом один сеанс блокирует другой, хотя по логике этого быть не должно. Кто знает в чём дело?

Пример кода сеанса 1.

НачатьТранзакцию(РежимУправленияБлокировкойДанных.Управляемый);

блок = Новый БлокировкаДанных;
элблок = блок.Добавить("РегистрСведений.Тест");
элблок.Режим = РежимБлокировкиДанных.Исключительный;
элблок.УстановитьЗначение("Измерение1", "1");

блок.Заблокировать();

Предупреждение("!");

ЗафиксироватьТранзакцию();

Пример кода сеанса 2.

НачатьТранзакцию(РежимУправленияБлокировкойДанных.Управляемый);

блок = Новый БлокировкаДанных;
элблок = блок.Добавить("РегистрСведений.Тест");
элблок.Режим = РежимБлокировкиДанных.Исключительный;
элблок.УстановитьЗначение("Измерение2", "2");

блок.Заблокировать();

ЗафиксироватьТранзакцию();

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(0) На каком наборе данных тестировали?
Измерение1 и Измерение2 Как разные Измерения одного и того же регистра.

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

Нам тут трудно видеть, что у вас там на заведено :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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