Для чего нужно свойство "БлокироватьДляИзменения " ? #641334

Не догоняю для чего это свойство нужно?. По документации:Устанавливает режим, при котором в процессе записи набора будет установлена управляемая блокировка для всех комбинаций измерений в соответствии с записями набора записей. Но...! 1. Блокировка наступит после записи набора, до записи момента записи пофиг что и как установлено. 2. Но если набор записать даже без установки этого свойства на набор автоматически накладывается управляемая блокировка системой по записи. Т.е. Движения.ОстаткиНоменклатуры.БлокироватьДляИзменения=Истина; .... Эквивалентно просто: .... В чем смысл этого свойства?!

дает скулю хинт shareforupdate

блокировка обновления

- при чем здесь скуль?. Я про логику 1С. Покажите мне различие поведения 1С с установкой и без установки оного свойства.

+ - и какой тогда хинт дает 1С при записи набора? :)

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

в 1с логика не всегда есть

на набор - да. На остатки и обороты - нет.

-  разжевываю проведенные мной тесты (по временным интервалам, естественно блокировки проводятся в разных документах): Методика работы предлагаемая 1С: (Для теста берем след. код Теперь просто пишем набор Так сказать найдите разницу. Что касается чтения данных - то данные читаются в 1С всегда независимо от блокировок (ну вернее  чуть сложнее с учетом работы SQL - на момент записи в таблицу блокируется а потом доступно)

- сначала не дошла суть сказанного. Действительно чтение остатков не тестировал. Надо попробовать

в твоем случае разницы нет; а вот если ты будешь контроль остатков делать после записи - разница появится

и в чем же она появится, если не секрет?

Данные читаются так как на них хинт стоит NOLOCK. Если же ты будешь использовать в транзакции то будут ждать. Ты кстати блокировке установи Блокировка.Режим = РежимБлокировкиДанных.Исключительный Исключительный или Разделяемый (Shared)

- итак в 1-м документ без всяких БлокироватьДляИзменения запись набора во втором: попытка чтения запросом        Запрос=Новый Запрос("ВЫБРАТЬ                            |    ОстаткиНоменклатурыОстатки.КоличествоОстаток - результат запрос не выполняется, данные блокированы! Итак вопрос открыт: что дает особенного данное свойство?

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

не так: Первая транзакция То есть без БлокировкаДанных

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

что не так? в первой транзакции просто запись без всяких установок БлокироватьДляИзменения : Движения.Номенклатура.Записать; во второй транзакции попытка к этим данным обратиться : результат - данные заблокированы (да и должно бы быть - вед идет запись, тут сам бог велел). Речь идет исключительно об управляемых блокировках.

Вопрос когда ж нужно использовать БлокироватьДляИзменения? То есть, тот случай, когда данные не блокируются просто при записи набора? Вот этого никак нащупать не могу?

У регистра установлена управляемая блокировка? Тестишь на скуле?

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

единственный момент для регистра не установлен разделение итогов. Сейчас попробую с установленным флагом

с разделением итогов то же самое

То бишь схема с установкой БлокироватьДляИзменения и без оной работает абсолютно одинаково (ну или я не нахожу различий). Так в чем же сакральный смысл в БлокироватьДляИзменения? :)

попробуй тогда

Сдается мне у тебя что то с технологией тестирования. В противном случае ты бы увидел блокировку на чтение, как это описано в документации.

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

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

- вы близки к истине, только объяснения не совсем понятны. В общем, разобрался с данной ситуацией. Итак резюме: 1. С точки зрения чтения данных и блокировки данных (именно "БЛОКИРОВКИ" как объекта 1С) - тут использование данного свойства не имеет смысла (что без его использования, что с его использованием поведение 1С одинаковое, а именно исключительная блокировка по всем комбинациям измерений). 2. Использование данного свойства имеет смысл только при "Разрешении разделении итогов" для регистра. И все, что оно делает, так это запрещает параллельную запись в регистр по комбинации измерений. Если не разрешено разделение итогов, то данное свойство так же не имеет смысла, ибо в этом случае система тоже блокирует одновременную запись, а вот при разделении итогов - тут запись пройдет, если не установить БлокироватьДляИзменения. Вот и весь сакральный смысл этого свойства. :) Спасибо всем, кто принял участие в дискуссии

А блокировки Исключительный или Разделяемый это разве не управляемые блокировки? По умолчанию изоляция блокировки Read Commited Была бы изоляция Repeatable read не было бы проблем с повторным чтением поэтому и приходится накладывать блокировки Разделяемый

смысл - блокировать меньше данных на меньшее время; реализуется как раз с помощью разделения итогов, контроля остатков ближе к концу транзакции и сабжа.

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

Я так понимаю, что БлокироватьДляИзменения  все же исключительная блокировка. Но суть получается такая, что если тебе после записи в регистр нужно обратиться к итогам до конца транзакции тебе нужно ее заблокировать. Разницы в для блокировок Исключительный или Разделяемый нет, так как изоляция Read Commited будет дожидаться окончания транзакции так как данные изменены. По идее блокироваться должны и записи в зависимости от свойства "Запись движения при проведении"например Записывать модифицированные будет блокировать только измененные.

- нет не так. БлокироватьДляИзменения  вообще никаким боком к режиму блокировки не относится. При записи набора ВСЕГДА устанавливается блокировка на записываемые данные, и как результат их нельзя получить запросом или заблокировать в другой транзакции. Но есть только одно НО! В случае разделяемых итогов 1С позволит во время блокировки записать набор по тем же измерениям если не установлено БлокироватьДляИзменения. Вот и все! и причем тут глубокие дебри про Read Commited, а  Записывать модифицированные и с ними иже си вообще к теме блокировки не имеют никакого значения .

где-то читал, что в режиме автоблокировок БлокироватьДляИзменения игнорируется

пардон, в режиме управляемых блокировок

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

Больше за этим НИЧЕГО не стоит.

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

ну так БлокироватьДляИзменения относится ТОЛЬКО к управляемым блокировкам. И как-то этим пользоваться в автоматических блокировках мысль не посещала

А при том, что изоляция Read Commited дает читать только неизмененные данные и ели данные изменены то ожидать окончания транзакции. По уму БлокироватьДляИзменения  имеет смысл только до записи. После записи уже вступает в силу уровень изоляции Read Commited.

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

несешь пургу, уже всё выше расписали

А поподробнее в чем пурга?

43+ Если и есть смысл использования то  только не для SQL.