Добрый вечер. Хочу для себя внести ясность в вопросе блокировок.
В статье на ИТС про блокировки (https://its.1c.ru/db/metod8dev/content/5839/hdoc) есть такие слова:

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

В какой момент нужно использовать пространство с суффиксом НаборЗаписей, а в использовать пространство без суффикса какой нет?

Например в УНФ в модуле набора записей регистра накопления "Запасы" есть вот такой код.

//Установка исключительной блокировки текущего набора записей регистратора.
Блокировка = Новый БлокировкаДанных;
ЭлементБлокировки = Блокировка.Добавить("РегистрНакопления.Запасы.НаборЗаписей");
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
ЭлементБлокировки.УстановитьЗначение("Регистратор", Отбор.Регистратор.Значение);
Блокировка.Заблокировать();

Подскажите чего хотели достичь разработчики УНФ установкой такой блокировки?

(77)Если что я код просто посмотрел, так как запустить я это не могу же, из-за отсутствия ExtendedFunc.dll как я понимаю, думаю ты в курсе этого.

(80) Потому что когда мы выставляем флаг БлокироватьДляИзменения, в наборах записей происходит пересечение областей блокировки по одинаковым значениям измерений. Вот поэтому происходит блокировка, которая нас не допускает до преждевременного выполнения запроса остатков. 1 транзакция ждет, пока вторая транзакция запишет свои расходыв базу и запрос будет выполняться с учетом этих расходов.

Если мы не выставляем флаг БлокироватьДляИзменения, области блокировок не пересекуться, так как к измерениям добавиться Разделитель, 1 транзакция не будет ждать 2 транзакцию и запрос контроля остатков выполнит без учета расходов 2 транзакции.

(81) Пардон, вот с компонентой
https://disk.yandex.ru/d/xk3N9YReFX0xcA

(82)Всё верно, именно так.

Подчеркну ещё раз то, в чём мы пытаемся разобраться и попытаюсь более подробно донести свою позицию.

Весь вопрос в том, ПОЧЕМУ при использовании БлокироватьДляИзменения = Истина, из полей блокировки исключается поле "разделитель"? Ведь благодаря этому и происходит конфликт блокировок.


1ый вариант. Вариант автора статьи на ИС и как оказалось не только на ИС. см.(69) автор в конце статьи.

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



2ой вариант. Официальный от 1С.

Описание из СП. Устанавливает режим, при котором в процессе записи набора будет установлена управляемая блокировка для всех комбинаций измерений в соответствии с записями набора записей.

Другими словами из статьи по ссылке - https://v8.1c.ru/platforma/upravlenie-blokirovkami-v-tranzakcii/
Действие этого свойства аналогично тому, как если бы разработчик самостоятельно установил (прописал в коде) нужные управляемые блокировки 1С:Предприятия 8. Необходимую управляемую блокировку платформа установит автоматически при записи этого набора записей. В результате другие управляемые транзакции, использующие аналогичную блокировку, не смогут начать читать этот регистр, пока не закончится текущая транзакция.

Прочитав статью про разделитель итогов - https://its.1c.ru/db/metod8dev/content/1393/hdoc

"Данный механизм работает только при записи движений. При обращении к итогам регистров в запросе блокировка накладывается на все записи с используемыми комбинациями измерений. И это соответствует сути решаемой задачи. Например, при проведении расходной накладной средствами встроенного языка выполняется считывание остатков для проверки возможности продажи товара. В этом случае блокировка не позволит провести расходную накладную параллельно с другой расходной накладной или приходной накладной, если имеются пересекающиеся комбинации  измерений. И это правильно, потому что, расходную накладную номер 5 нельзя проводить параллельно с приходной накладной 1 и приходной накладной 5, так как необходимо обеспечить логическую проверку наличия товара на складе, так чтобы никто не мог поменять считанный остаток до конца транзакции проведения расходной накладной. Таким образом, механизм разделения итогов исключает блокировки, устанавливаемые для поддержки актуальных итогов (решения системной задачи), но не исключает блокировки, накладываемые для решения задач бизнес-логики."

мы понимаем что существует блокировки для решения системной задачи и для решения задач бизнес логики.
Блокировки которые платформа ставит для решения системной задачи(как раз та платформенная блокировка упомянутая в варианте от автора статьи), игнорируются механизмом разделения итогов.
А вот блокировки устанавливаемые для решения задач бизнес-логики, то есть те блокировки которые пишет разработчик(платформа же не отвечает за бизнес-логику), механизм разделения итогов не исключает и происходит конфликт блокировок.

Исходя из вышенаписанного делаю вывод, что будет установлена управляемая блокировка(для решения задачи бизнес-логики - контроля остатков) как я понимаю ВМЕСТО неявной блокировки и благодаря этому, произойдёт конфликт блокировок.

То что свойство называется "БлокироватьДляИзменения" понятно, потому что это аналог конструкции "ДЛЯ ИЗМЕНЕНИЯ" в запросе, которая использовалась до управляемых блокировок. Её нужно было использовать
чтобы передать команду СУБД установить блокировку на читаемые значения.
Из статьи - https://its.1c.ru/db/metod8dev/content/5839/hdoc

При этом разделяемая блокировка устанавливается для того, чтобы данные не были изменены другими транзакциями. Исключительная блокировка, помимо этого, обеспечивает запрет не только изменения этих данных, но даже их чтения другими транзакциями, устанавливающими управляемые блокировки. Можно сказать, что исключительная управляемая блокировка является средством борьбы с конфликтами блокировок (deadlock) и может использоваться аналогично ключевому слову ДЛЯ ИЗМЕНЕНИЯ языка запросов в режиме автоматических блокировок.
Следует помнить, что чтение данных другими транзакциями будет невозможно только в том случае, если в других транзакциях устанавливаются несовместимые управляемые блокировки. Если управляемые блокировки в других транзакциях не устанавливаются, то чтение будет возможно. Это аналогично тому, как конструкция ДЛЯ ИЗМЕНЕНИЯ препятствует чтению данных не любыми запросами, а только теми, которые тоже используют конструкцию ДЛЯ ИЗМЕНЕНИЯ.




Итак, что по итогу мы имеем?
Описание из СП платформы 1С говорит что будет установлена блокировка.
Описание из статьи с сайта 1С говорит о том, что будет установлена блокировка.
Описание механизма разделения итогов с ИТС говорит нам о том, что механизм разделения итогов исключает одни блокировки, и не исключает другие блокировки(Не говорится что есть некое свойство отключающее механизм разделения итогов)
Название говорит нам о том, что мы хотим что-то Заблокировать Для Изменения.

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


В своей работе мне не приходилось сталкиваться с блокировками, так как не приходилось работать с высоконагруженными системами, ну в общем не было опыта.
Сейчас же мне понадобилось понять и изучить этот механизм, я читаю, вникаю, разбираюсь и не могу понять, почему большинство вместо того, чтобы верить данным от разработчика
принимает субъективный взгляд одного человека? Я понимаю что результат один и тот-же, но ошибочное понимание этого процесса мешает правильному пониманию его работы и соответственно
правильно его применять. В статье автор просто ставит в условие что свойство нужно использовать ТОЛЬКО при новой методике контроля остатков, но это не так.
Например я хочу сразу после записи не проконтролировать остатки, а например понять, не превысил ли я лимит чего-нибудь, или поместится результат записи куда-нибудь, да
много разных примеров можно привести, смысл же в том, что установить блокировку и работать с неизменяемыми данными.

В этом видео виден результат прочтения таких вот статей - https://youtu.be/p1aFZSC8qbg?t=3088
На 29:00 и в писании к видео Павел как раз и рекламирует эту статью.

А в видео он по факту ставит лишнюю блокировку(видимо не понимая что БлокировкаДанных которую он ставит, и так не будет исключена механизмом разделения итогов) на записи которые будут удалены при записи регистра, и соответственно на эти записи будет наложена блокировка и параллельно никто по этим записям приходную накладную уже не проведёт.

Павла я ни сколько не хочу упрекнуть в чём-то, просто возможно он не сделал бы такой ошибки, если бы не доверился статье, и все кто его смотрит не перенял бы этот опыт.
Ему конечно же ОГРОМНЕЙШЕЕ спасибо за его труд, за то что он многих из нас сделал 1Сниками.

https://www.youtube.com/watch?v=u75lqTdBjXc

(86)Денис, доброе утро. Ссылку на это видео я уже давал в этой теме в посте (80)
Что вы хотели этим сказать? :)

Автор видео кстати не в курсе того, что бывают разные варианты реализации изоляций транзакций в СУБД. Иначе он бы не удивлялся тому, что блокировка при чтении не происходит.

Чёт на (85) никакого дальнейшего обсуждения не последовало.. Либо я плохо объясняю, либо хз..

Попробую как вариант оформить это в виде статьи на ИС, может быть там люди ткнут меня носом, направят на путь истинный приведя неопровержимые факты.

(88)Очень много буков. По поводу блокировок - 1С по моему  Объясняет все наполовину. И на этой почве кстати появляются товарищи которые не проясняют а не понятно вообще что делают еще и деньги берут. Если хочешь докопаться так сказать до конца, надо наверное читать что-то типа блокировки в мс скл.

(89)Так в (85) и не пособие по блокировкам, это рассуждения на тему того, как неверно можно истолковать поведение программы и ввести в заблуждение группу людей.

У нас разговор про управляемые блокировки в 1С, причём тут блокировки в МС СКЛ? Управляемые блокировки в 1с только называются блокировками, по факту они ничего не блокируют, это механизм который позволяет работать с СУБД с более низким уровнем изоляции транзакций и в тоже время обеспечивать неизменность данных тогда когда это необходимо.

(90) https://youtu.be/tBONXbtiIR8

(91)Не конструктивно же :)
Давайте по существу, что вам не понравилось в (90)? :)

"Управляемые блокировки в 1с только называются блокировками, по факту они ничего не блокируют"
Мдя...

(92) "по факту они ничего не блокируют"

(94) Это аналогично выражению "блокировки в SQL только называются блокировками, по факту они ничего не блокируют"

А что они по вашему блокируют?
Если установлена управляемая блокировка записи из базы нельзя удалить?

Или mutex-ы в winapi только называются mutex-ами, по факту они ничего не mutex-уют.

(95)Блокировки в SQL это блокировки в SQL, они блокируют записи. А управляемые блокировки в 1С записи в базе данных не блокируют.

(98) Конечно записи они не блокируют. Но они не позволят другой транзакции удалить эти записи, потому что другая транзакция перед удалением попробует тоже установить блокировку.
Один в один как SQL прям.

(99) Конечно записи в СУБД они не блокируют.

(94)https://its.1c.ru/db/metod8dev/content/5839/hdoc

Вот цитата:

ВНИМАНИЕ

Следует понимать, что, в данном случае речь не идет о реальных записях базы данных. Несмотря на то, что управляемые блокировки описываются в терминах объектов метаданных и их полей, эти блокировки никак не связаны с реальной структурой хранения данных 1С:Предприятия в СУБД. Это всего лишь записи о том, что заблокировано «нечто».

Иногда можно провести аналогию между управляемыми блокировками и реальными записями СУБД. Например, для объектных данных блокировка объекта с указанной ссылкой будет «соответствовать» блокировке всех записей, содержащих указанную ссылку, во всех таблицах этого объекта метаданных (в основной таблице и в таблицах его табличных частей).

Однако в других случаях провести такую аналогию достаточно затруднительно, да и не нужно. Например, блокировка регистра бухгалтерии с указанием значения вида субконто. Достаточно понимать, что накладывая такую блокировку мы запрещаем другим транзакциям каким-либо образом изменять «записи» регистра бухгалтерии, у которых значение вида субконто равно указанному нами. Как при этом данное условие «проецируется» на реальную структуру данных регистра бухгалтерии - для нас совершенно не важно.

При установке новых блокировок менеджер анализирует имеющиеся блокировки. Если оказывается, что «нечто», что мы пытаемся заблокировать, уже заблокировано ранее, сравниваются режимы существующей и новой блокировок. Если режимы совместимы - новая блокировка устанавливается. Если режимы не совместимы - новая блокировка ожидает снятия существующей блокировки.


А вот определение что такое управляемая блокировка из этой же статьи:

В общем случае блокировка - это информация о том, что данный ресурс захвачен «кем-то», для выполнения какого-то действия.

Интересно а как упр блокировки блокируют чтение. Ведь скл ничего про них не знает

(99)Попробуй выполнить удаление записей в СУБД тогда, когда на них установлена управляемая блокировка в 1С и скажешь результат.

(101) тебе бы с асинхронными сокетами поработать бы.

(101) @сего лишь записи о том, что заблокировано «нечто».@
Я тебе открою секрет - блокировки в СУБД - тоже только запись. И они мне не помешают удалить файл БД.

(102) А читают не через скл, а через сервер 1с. А он знает.

(105)Так-то и диск сломать можно :)

(106) так я же запросом. Откуда сервер 1с знает попадется ли в запросе заблокированное

В (90) я отвечал на (89), говоря что смысла читать про блокировки в СКЛ нет, если хочешь разобраться с вопросом который я поднял..

(108)Прочитайте статью с яблоками

Вот картинка которая может помочь
https://its.1c.ru/db/content/metod8dev/src/developers/scalability/standards/i8105839.files/ch03_016.png?_=00000F11D9778341-v2

(90)Я для себя определил так: есть блокировки объектные(заблокировать), есть менеджер блокировок 1С и есть блокировки СУБД. Пока вся картинка не сложилась постоянно внутренний дискомфорт испытывал ибо не может сказать как 1С себя поведет.

(108) Он-то узнает...

(111)Не могу сказать что у меня вся картинка сложилась, но для того чтобы правильно понять "БлокироватьДляИзменения" моей картинки уже хватает.

(108)Если упр блокировку не поставишь то походу даст прочитать. даже в транзакции.

Пытаюсь понять, о чем спор.
О какой статье на ИС идет речь, начиная с (34)? Не вижу ссылки.

(114)Только если изоляция достигается за счет версионности, а если используются блокировки тогда не даст.

(115) в (69)

(116)Он пишет про сервак 1С.

(118)Извините, не хочу обидеть, но не могу отвечать больше, вам нужно осилить статью про яблоки.

(117) А почему ссылка не от тебя? Сам сначала путаешь, потом хочешь разобраться. :)

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

(120)Я сам не давал ссылку, чтобы от кого-нибудь получить другую ссылку на аналогичный материал, чего и достиг в (69), чтобы понять где-то ещё пишут такое же что пишет автор этот статьи или всё это понятие "Отключает/игнорирует разделитель итогов" пошло от одной его статьи.

Ссылку я получил на вторую статью, но автор оказался тот-же..

(121) Дай ссылку на первую.

(108)Ничего он не блокирует на чтение пока упр. блокировку явно не укажешь. Надо явно блокировки ставить. Исключение - запись. А там все известно. проверил чтение запросом в транзакции в отчете.

(122)Так там же в (69) обе ссылки..

Я знал только про статью на ИС, а на статью с сайта КурсыПо1С не знал..

(124) Похоже, на ИС сокращенная версия.

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

(125)
Не бойтесь хвалы, не бойтесь хулы,
Не бойтесь мора и глада,
А бойтесь единственно только того,
Кто скажет: "Я знаю, КАК НАДО!"
Кто скажет: "Идите, люди за мной!
Я вас научу, КАК НАДО!"

(126)
Много неясного в странной стране —
Можно запутаться и заблудиться…
Даже мурашки бегут по спине,
Если представить, что может случиться.
Вдруг будет пропасть — и нужен прыжок.
Струсишь ли сразу? Прыгнешь ли смело?
А? Э-э! Так-то, дружок,
В этом-то всё и дело.

Я кажется понял, где именно автор сам заблудился.
Цитата:

--------------
Если до записи движений установить данное свойство в значение «Истина», то блокировка будет накладываться без учета разделителя. То есть поведение будет таким, как будто разделитель итогов у регистра выключен.

Следует отметить что блокировка будет наложена вне зависимости от значения данного свойства. Если БлокироватьДляИзменения имеет значение «Истина», то блокировка будет без учета разделителя, иначе – с учетом разделителя. По умолчанию значение свойства БлокироватьДляИзменения равно «Ложь».
--------------

В документации сказано (https://its.1c.ru/db/metod8dev/content/5839/hdoc/hdoc)), что у регистра накопления два пространства блокировок: 1) РегистрНакопления.<имя>.НаборЗаписей для блокировок ЗАПИСЕЙ по регистратору, и 2) РегистрНакопления.<имя> для блокировок наборов ИЗМЕРЕНИЙ. Принципиальное отличие в том, что блокировку по измерениям можно наложить независимо от наличия записей в регистре.

При записи набора, разумеется, всегда накладывается блокировка на записи этого набора (извиняюсь за тавтологию). независимо от свойства БлокироватьДляИзменения. А при установленном свойстве БлокироватьДляИзменения дополнительно еще накладывается блокировка на наборы измерений, присутствующие в этом наборе (опять тавтология, но надеюсь, понятно). Разницы между ними невооруженным глазом не видно. Отсюда и путаница.

Разделитель итогов это фактически детали реализации. И то, что в описании свойства БлокироватьДляИзменения он не упомянут, это правильно.

(128) "блокировка на наборы измерений, присутствующие в этом наборе"
Регистратор входит в этот набор?

(130) Регистратор к измерениям не относится :)

(128)При записи набора, разумеется, всегда накладывается блокировка на записи этого набора (извиняюсь за тавтологию). независимо от свойства БлокироватьДляИзменения. А при установленном свойстве БлокироватьДляИзменения дополнительно еще накладывается блокировка на наборы измерений, присутствующие в этом наборе (опять тавтология, но надеюсь, понятно). Разницы между ними невооруженным глазом не видно.

Это неверно.

Если вы считаете что при записи набора идёт попытка установки блокировки с именем пространства включающим суффикс "НаборЗаписей"(РегистрНакопления.<имя>.НаборЗаписей), то это не так.

При записи набора данных происходит попытка установки управляемой блокировки с именем пространства без суффикса "НаборЗаписей"(РегистрНакопления.<имя>), которая включает в поля блокировки поле - "Разделитель".
А если поставить свойство БлокироватьДляИзменения, то блокировка изменится, так как поле "Разделитель" не будет включено в поля блокировки.
Но это не значит что свойство "БлокироватьДляИзменения" отключает/игнорирует разделитель итогов, так мыслить нельзя. Можно мыслить вот так если хочется - при установке свойства будет изменена/заменена неявная блокировка, и таким образом она станет похожей/такой же как если бы мы установили явную блокировку.
В (85) всё это написано.

А блокировка с именем пространства включающее суффикс "НаборЗаписей" будет конфликтовать только с такой-же блокировкой у которой имя пространства включает суффикс. Это мы разбирали с (0) до (30) а дальше почти всё уже про "БлокироватьДляИзменения"
Другими словами если установить такую блокировку на набор записей в котором есть товар "Стол" например, то всё равно можно будет проводить приходы и расходы, никакого конфликта блокировок не будет.

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

Если руками ставишь блокировку, то она всегда БЕЗ разделителя

(133)Это верно, да.

(132) > Если вы считаете что при записи набора идёт попытка установки блокировки с именем пространства включающим суффикс "НаборЗаписей"(РегистрНакопления.<имя>.НаборЗаписей), то это не так.

Как же не так, когда об этом сказано в документации, и в трассе (38) это хорошо видно.

(135)В (38)блокировка с именем пространства без суффикса "НаборЗаписей"(РегистрНакопления.<имя>).

Приведите цитату из документации, попробуем разобраться.

Ну и чтобы действительно быть уверенным, попробуйте смоделируйте ситуацию и увидите что блокировка РегистрНакопления.<имя>.НаборЗаписей не конфликтует с блокировкой РегистрНакопления.<имя>

А автор статьи серьёзный специалист, он не "заблудился" и всё верно понимает в этом плане, но называет вещи не своими именами, в этом и проблема. Потому что от его объяснений люди делают ошибки.

Если бы он не написал статью и все бы нормально понимали что если написать БлокироватьДляИзменения = Истина; будет тоже самое что и при использовании объекта "БлокировкаДанных" ошибок было бы меньше.
А если бы захотели копнуть глубже, поняли бы что просто поле "Разделитель" не входит в поля блокировки.

(136) В (38) есть и та, и другая. AccumRg86.RECORDER и AccumRg86.DIMS.

>не конфликтует

Не конфликтует. Никто вроде и не утверждал, что конфликтует.

(137)Да, спасибо!! Вижу теперь :) С набором записи теперь стало ещё более логично и понятно!

Итак в (132) я написал неверно. Вы правы, спасибо что помогли мне ещё один кирпичик уложить в голове. В скриншот Димы смотрел, искал даже как будет отличное от .DISM и как говорится смотрел в книгу, видел фигу :)

Значит при записи идут 2 неявные блокировки и на оба пространства имён.

Но в (128) всё равно не верно получается блокировка на измерения про которую вы говорите накладывается и без установки свойства - "БлокироватьДляИзменения".

(136) Руководство разработчика у меня в бумажном виде, поэтому цитата будет вот такая: https://imgur.com/a/zwkxf8x

(139)Это всё понятно :) Крутяк что в бумаге есть :)

(138) >блокировка на измерения про которую вы говорите накладывается и без установки свойства - "БлокироватьДляИзменения".

Это детали реализации. Я бы и сам не прочь узнать их подробнее. Но только "с пруфами", а не в стиле статьи Бурмистрова.

(141)Так в скрине же видно тоже.. Сначала идёт блокировка без Splitter, затем с ним.

(141)Это он тест делал, что пишется в ТЖ если поставить свойство БлокироватьДляИзменения и не поставить его.

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

Я сам не хочу пока дорастать до ТЖ, нет необходимости в этом пока что, поэтому не буду перегружать голову.

(142) Не будем уподобляться Бурмистрову и полагать, что так всегда.

(145)Ну так в статье про разделитель итогов чётко написано, что блокировка ставится.

https://its.1c.ru/db/metod8dev/content/1393/hdoc

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

Да и в других статья об этом пишут и даже книгах, если судить по вашем скрину :)

(146) Я бы посмотрел, например, на трассу с отключенным разделением итогов.

(148)Ну вроде понятно как там будет, одно поле "номенклатура" будет в блокировке и всё, а в таблице итогов не будет лишней колонки "Разделитель" и всё будет норм.

Ну если Дима будет не против, может сделает нам.. ну или если на меня найдёт, я соберусь, но уже в выхи..

(149) Но будет ли блокировка измерений без БлокироватьДляИзменения?

Доброе утро. В (144) Конечно же я хотел написать "БлокировкаДанных".


(150)Я бы лучше подумал вот над таким вопросом из статьи на Курсы 1С РФ

Вопрос 3

Нужно ли устанавливать БлокироватьДляИзменения при очистке движений?

Ответ

В большинстве случаев не нужно, так как обычно после очистки движений контроль остатков не выполняется. Если контроль сразу после очистки выполняется, тогда БлокироватьДляИзменения ставить нужно.


Верный ли ответ дал автор статьи в этом вопросе?

что тебе мешает вместо набора имя регистра использовать?

(152)Мы отошли от темы ветки и обсуждаем уже БлокироватьДляИзменения.. Про суффикс НаборЗаписей вроде разобрались немножко.

(153) А что неясно с БлокироватьДляИзменения? Как уже говорили, оно имеет смысл только с разделителем. Лень искать, но это где-то явно объясняется и стопудов в этой ветке уже перетирали.
При записи в любом случае будет наложена эксклюзивная блокировка на изменяемую строку таблицы итогов. И не будь разделителя - не было бы никакого смысла в дополнительных приседаниях. Но разделитель меняет правила игры, так как специально позволяет параллельно писать по той же комбинации измерений. И когда мы хотим это запретить - используем это пресловутое БлокироватьДляИзменения.

(154) > При записи в любом случае будет наложена эксклюзивная блокировка на изменяемую строку таблицы итогов. И не будь разделителя - не было бы никакого смысла в дополнительных приседаниях.

Ты имеешь в виду блокировку на уровне СУБД? Тогда последнее неверно. Напомню, СУБД у нас работает в режиме изоляции read commited, а чтение не блокируется. Две конкурирующие транзакции на списание могут увести остаток в минус. Для решения этой проблемы ввели блокировку измерений (пространство РегистрНакопления.<имя>). А свойство БлокироватьДляИзменения это лишь удобный способ наложить нужные блокировки. Все это одинаково работает и с разделителем, и без.

(154)Что происходит технически мы понимаем и уже перетёрли не один раз.
Меня не устраивает формулировка "БлокироватьДляИзменения отключает/игнорирует разделитель итогов". И из-за того что один человек стал это так трактовать и разнёс это на всё сообщество люди неверно понимают как им использовать это свойство.

Если есть возможность лучше скажите что-нибудь по поводу - (151), если нужно можно в (69) почитать вторую ссылку, это оттуда.

(156) Ну, да. Формулировка не совсем удачная. Но и "БлокироватьДляИзменения" - тоже не совсем точно передает суть происходящего. Но как-то эту хрень назвать надо было.
(151) Хм... Если при очистке с БлокироватьДляИзменения устанавливается управляемая блокировка без учета разделителя на комбинации измерений всех удаляемых записей, то по-идее это нужно тогда, когда нам могут понадобиться гарантированные остатки по этим комбинациям. А это действительно скорее исключение, чем правило. Ведь для оптимистического контроля остатков новых позиций мы все равно будем БлокироватьДляИзменения и тогда для нашей транзакции блокировки остальных позиций при очистке неважны. А для параллельной транзакции достаточно будет и того, что заблокировались удаляемые записи с учетом разделителя и она не сможет наложить на нужные ей измерения эксклюзивную блокировку без учета разделителя до конца нашей транзакции.

(151) То есть - да. Ответ верный. Хоть и не предельно ясный.

(151) Ответ верный, с учетом "в большинстве случаев". Очистка движений в общем случае может менять остатки как в плюс, так и в минус. Нужно понимать, насколько это важно для этой и для других параллельных транзакций в конкретном сценарии.

(157) > "БлокироватьДляИзменения" - тоже не совсем точно передает суть происходящего.

В чем же неточность? Перейдем теперь к твоим заблуждениям?

(160) Хотел вот ответить, что ты в (159) какую-то глубокомысленную чушь написал. Но сдержался. Но теперь не сдержусь :)

(161) Не отрицаю. :) Каков вопрос, таков ответ.

(157)Как раз удачная формулировка. Всё именно так как надо.
Пример.
Если мы хотим чтобы движения записались в обработке проведения мы пишем - "Движения.ОстаткиТоваров.Записывать = Истина;"
Тут можно придраться аналогично как автор статьи придирается к свойству "БлокироватьДляИзменения" сказав - Свойство "Записывать" ничего не записывает!!! При его установке мы говорим системе - запиши движения плиз. Так-же и при установке свойства "БлокироватьДляИзменения" мы говорим системе - поставь блокировку плиз.

Второй абзац в (157) как мёд просто прочитал.. Приятно читать, видя что человек понимает.
И всё верно написано.

Но мне кажется то что написано в этом абзаце никак не сочетается с тем, что написано в (158)

Чтобы разобраться, давайте разберём пример, в котором при очистке движений мы ставим свойство "БлокироватьДляИзменения" и это верно, можете такой пример привести?

p.s. странно, но мне понятно то, что написано в (159).

(158)То есть что я хочу сказать. Обычно остатки мы контролируем когда? Когда проводим списание, верно? Ну и зачем же в этом случае нам ставить БлокироватьДляИзменения при очистке движений?
Я считаю что в этом примере ставить не то что можно и типа хуже не будет, а наоборот категорически нельзя, так как это будет излишняя блокировка.

(163) > Но мне кажется то что написано в этом абзаце никак не сочетается с тем, что написано в (158)
Если по какой-то причине нам нужно получить гарантированные остатки по комбинациям измерений удаляемых строк (но придумать нахрена нам это может быть надо я сходу не могу), то вот же оно - положила :)
ИМХО, ответ на то и нацелен, что обычно не надо. Но не исключен какой-то хитрый вариант, когда вдруг и надо.
> p.s. странно, но мне понятно то, что написано в (159)
Мне тоже понятно. Но там нет ответов ни на какой вопрос.

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

>ИМХО, ответ на то и нацелен, что обычно не надо. Но не исключен какой-то хитрый вариант, когда вдруг и надо.

А мне кажется автор немножко запутался, потому что это статья для обычных людей, и отвечать вот так - "Если контроль сразу после очистки выполняется, тогда БлокироватьДляИзменения ставить нужно." тут нельзя, люди неверно понимают это и начинают лепить БлокироватьПриИзменении при удалении движений расходных накладных.

Пример такой есть в (85) внизу, ссылка на видеорок, она с таймкодом.

http://memesmix.net/media/created/kakiqi.jpg

Подытожу что-ли..

Я так понял моя позиция неверная и её никто не поддерживает кроме mistera? :)

Или всё же есть какой-то смысл в моих умозаключениях?

(168) Резюмируй свою позицию, что ли, раз хочешь подытожить. Насколько я понял, ты просто бурчишь что мало кто умеет объяснять сложные вещи простыми словами. Ну дык такова селяви.

(169)
Моя позиция подробно описана в (85)
Если в кратце, то vеня не устраивает что из-за одной статьи, из-за одного неверного мнения многие люди используют формулировку - "БлокироватьДляИзменения отключает/игнорирует разделитель итогов", которая на мой взгляд неверна. Верна формулировка от 1С, котороая в статьях, в СП, и т.д.
И люди даже не то чтобы используют такую формулировку, а воспринимают "в штыки", когда им говоришь что БлокироватьДляИзменения устанавливает блокировку, это как религия уже :)

(170) Предлагаю промоделировать самостоятельно и написать свою статью, правильную. С пруфами, с трассами,  и т.д.. Отработать все сценарии, даже разные версии платформы. Если все сделать на хорошем уровне, это будет действительно круто. И проблему, которая тебя беспокоит, решит кардинально. Что люди читают ту статью и делают неправильно.

(170) Тебе не нравится формулировка в статье. Но в корне неправильной ее назвать нельзя - она просто плохая. Как и формулировка от 1С плохая. Они обе не дают полного представление о том, что происходит.
Да, установка свойства БлокироватьДляИзменения ничего не блокирует. В этом автор статьи прав :)
Блокировка будет наложена только в момент записи, причем в любом случае. И при наложении блокировки разделитель либо будет проигнорирован либо не будет - в зависимости от значения свойства БлокироватьДляИзменения.

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

(173)А с точки зрения что ты пишешь статью для людей, которые не понимают что делает свойство БлокироватьДляИзменения, для людей у которых ещё не сформировалось верное представление о механизме работы блокировок.. Они обучаются и их цель заблокировать проведение других документов которые работают с данными регистром и тут им говорят - Это свойство ничего не блокирует бла бла бла, блокировка и без этого свойства есть и т.д. Верно ли они усвоят материал? А если бы они просто поверили СП и посчитали что будет установлена такая же блокировка как и при использовании объекта БлокировкаДанных, то вопросов больше бы и не было и всё было бы правильно.

Да и помимо просто формулировки в статье есть куча моментов бредовых, например что свойство нужно использовать ТОЛЬКО при новой методике контроля остатков..
Ну или даже ответ на вопрос который я писал в (151) тоже не корректен и вводит в заблуждение.

(174) Соболезную я твоим коллегам.

(175)Не конструктивно и не по тебе.. :)

(174) Мне кажется, твоего зуда должно хватить на написание "правильной" статьи по блокировкам. Тройная польза будет.

(177)Чтобы что-то писать, я должен быть уверен, что пишу верную информацию, я пока что не получил такого подтверждения.
Попытался утром подытожить, не увидел что большинство высказалось подтверждая мою позицию.
Какой можно сделать вывод - мои доводы не верны. И если тут спустя неделю обсуждений я не нашёл понимания, значит я ошибаюсь и смысл писать статью чтобы столкнуть с таким же непониманием, я не вижу..

Не хочется стать Джордано Бруно :)

Ну да, ну да...
Так же и самому объектом критики стать недолго.
Ну, тогда продолжай критиковать, если еще не надоело.
Истины он у большинства искать собрался...

(178) >я должен быть уверен, что пишу верную информацию

Ты кажется пропустил главное слово в (171).