Что на самом деле делает свойство «БлокироватьДляИзменения»

16.08.17

Разработка - Механизмы платформы 1С

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

Что бы понять материал данной статьи, нужно хорошо знать и понимать 2 вещи:

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

2. Новая методика контроля остатков (остатки контролируются после записи)

 

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

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

Но как быть, если например у регистра есть 2 регистратора, и один документ использует контроль остатков, а второй нет?

В этом случае нам как раз и пригодится свойство набора записей регистров накопления и бухгалтерии «БлокироватьДляИзменения».

 

Начнем с того, что использовать «БлокироватьДляИзменения» имеет смысл, только если выполняются все следующие условия:

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

 

Если хотя бы одно из этих условий не выполняется, то нет смысла использовать «БлокироватьДляИзменения».

Поэтому все сказанное ниже применимо только если выполняются все 3 условия.

 

А что это свойство делает?

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

 А поподробнее?

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

«… оно игнорирует разделитель итогов»

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

Повторю еще раз, свойство фактически ничего не блокирует, блокирует платформа без вашего участия, свойство лишь на время игнорирует разделитель итогов по данному набору измерений.

 

А зачем вообще игнорировать разделитель итогов?

Если не отключить разделитель итогов, то платформа накладывает управляемую блокировку по ключу Склад+Товар+Разделитель.

В результате возможны следующие последствия:

При использовании СУБД блокировочника - возможна взаимоблокировка.
При использовании версионника - возможно списание остатков в минус.

 

Давайте разберем эти случаи подробнее.

Если используется блокировочник.

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

Схема этой взаимоблокировки представлена в таблице.

В этом случае, по своему назначению, «БлокироватьДляИзменения» это аналог параметра «ДЛЯ ИЗМЕНЕНИЯ» в запросе чтения остатков в автоматическом режиме, только работает иначе.

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

При использовании «БлокироватьДляИзменения», блокировка является следствием отключения разделителя итогов для предотвращения  дедлока. Можно сказать, что это своего рода полезный побочный эффект.

Но даже если бы мы не использовали БлокироватьДляИзменения (и рискнули нарваться на дедлок), то остатки в минус все равно бы не списались, т.к. все нужные строки по ключу Склад+Товар (без учета разделителя) были бы заблокированы запросом остатков.

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

 

Если используется версионник

В этом случае, заблокированные строки первой транзакции, никак не помешают 2-й транзакции прочитать остатки (т.к. в версионнике пишущие не блокируют читающих).

Вторая транзакция спокойно прочитает старую версию данных (версию на момент начала первой транзакции) и спишет остаток в минус.

Что бы этого не допустить нужна управляемая блокировка на уровне 1С.

Если поставить БлокироватьДляИзменения = Истина, мы как раз получим такую блокировку, и данные будут заблокированы на уровне платформы.

 

«по записываемому набору измерений»

Разделитель игнорируется только для данного набора измерений.

Это значит, что режим разделения итогов на регистр в целом сохраняется и если у других наборов измерений БлокироватьДляИзменения =  Ложь, то они могут быть записаны параллельно.

 

Пример:

Допустим что одновременно встретились 6 транзакций и попытались одновременно записать данные в регистр, при этом разделитель итогов естественно включен.

Первые 2 транзакции делают расход и контролируют остатки, другие 4 делают приход и контроль остатков им не нужен.

Тогда мы получим такую картину.

Транзакция 1 оказалась на долю секунды быстрее всех и в момент записи данных установила исключительную управляемую блокировку без учета разделителя итогов (т.к. БлокироватьДляИзменения = Истина)

Транзакции 2 и 6 ждут Транзакцию 1, т.к. набор измерений у них одинаковый.

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

Транзакции 3 и 4 успешно записали свои данные параллельно, т.к. включен разделитель (БлокироватьДляИзменения = Ложь).

Транзакция 5 успешно записала данные параллельно, т.к. используется отличный от транзакции 1 набор измерений. 

 

«начиная с момента записи до конца транзакции»

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

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

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

Таким образом, если произойдет откат транзакции, свойство автоматически примет значение «Ложь» 

 

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

Ровным счетом ничего, не будет даже ошибки, просто данная строка кода будет проигнорирована.

 

А как же явные управляемые блокировки, они теперь не нужны?

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

 

А можно пример?

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

В таком случае код модуля проведения будет выглядеть следующим образом:

 

Процедура ОбработкаПроведения(Отказ, Режим)
	
    // регистр ОстаткиТоваров Расход
    Движения.ОстаткиТоваров.Записывать = Истина;
    Для Каждого ТекСтрокаТабличнаяЧасть Из ТабличнаяЧасть Цикл
        Движение = Движения.ОстаткиТоваров.Добавить();
        Движение.ВидДвижения = ВидДвиженияНакопления.Расход;
        Движение.Период = Дата;
        Движение.Склад = Склад;
        Движение.Товар = ТекСтрокаТабличнаяЧасть.Товар;
        Движение.Количество = ТекСтрокаТабличнаяЧасть.Количество;
    КонецЦикла;

    Движения.ОстаткиТоваров.БлокироватьДляИзменения = Истина;
    Движения.Записать();
    // Далее код проверки остатков …
КонецПроцедуры

 

Строку «Движения.ОстаткиТоваров.БлокироватьДляИзменения = Истина;» можно писать в любом месте процедуры, для удобства лучше это делать в конце.

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

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

 

Выводы:

  1. Данное свойство нужно использовать, только если соблюдаются все 3 условия:
    • транзакция выполняется в управляемом режиме
    • у регистра включен режим разделения итогов
    • используется новая методика контроля остатов (остатки контролируются после записи) 
  2. Несмотря на название, свойство ничего не блокирует, оно просто говорит платформе что блокировка нужна без учета разделителя.
  3. При использовании «БлокироватьДляИзменения», явные управляемые блокировки ставить не нужно.

См. также

Поинтегрируем: сервисы интеграции – новый стандарт или просто коннектор?

Обмен между базами 1C Администрирование СУБД Механизмы платформы 1С Платформа 1С v8.3 Бесплатно (free)

В платформе 8.3.17 появился замечательный механизм «Сервисы интеграции». Многие считают, что это просто коннектор 1С:Шины. Так ли это?

11.03.2024    3639    dsdred    48    

66

Как готовить и есть массивы

Механизмы платформы 1С Платформа 1С v8.3 Бесплатно (free)

Все мы используем массивы в своем коде. Это один из первых объектов, который дают ученикам при прохождении обучения программированию. Но умеем ли мы ими пользоваться? В этой статье я хочу показать все методы массива, а также некоторые фишки в работе с массивами.

24.01.2024    5045    YA_418728146    25    

62

Планы обмена VS История данных

Обмен между базами 1C Механизмы платформы 1С Платформа 1С v8.3 Бесплатно (free)

Вы все еще регистрируете изменения только на Планах обмена и Регистрах сведений?

11.12.2023    6175    dsdred    36    

110

1С-ная магия

Механизмы платформы 1С Бесплатно (free)

Язык программирования 1С содержит много нюансов и особенностей, которые могут приводить к неожиданным для разработчика результатам. Сталкиваясь с ними, программист начинает лучше понимать логику платформы, а значит, быстрее выявлять ошибки и видеть потенциальные узкие места своего кода там, где позже можно было бы ещё долго медитировать с отладчиком в поисках источника проблемы. Мы рассмотрим разные примеры поведения кода 1С. Разберём результаты выполнения и ответим на вопросы «Почему?», «Как же так?» и «Зачем нам это знать?». 

06.10.2023    18206    SeiOkami    46    

116

Дефрагментация и реиндексация после перехода на платформу 8.3.22

Механизмы платформы 1С Платформа 1С v8.3 Бесплатно (free)

Начиная с версии платформы 8.3.22 1С снимает стандартные блокировки БД на уровне страниц. Делаем рабочий скрипт, как раньше.

14.09.2023    11783    human_new    27    

72

Валидация JSON через XDTO (включая массивы)

WEB-интеграция Универсальные функции Механизмы платформы 1С Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

28.08.2023    8568    YA_418728146    6    

139

Внешние компоненты Native API на языке Rust - Просто!

Механизмы платформы 1С Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Внешние компоненты для 1С можно разработывать очень просто, пользуясь всеми преимуществами языка Rust - от безопасности и кроссплатформенности до удобного менеджера библиотек.

20.08.2023    6207    sebekerga    54    

93

Все скопируем и вставим! (Буфер обмена в 1С 8.3.24)

Механизмы платформы 1С Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Рассмотрим новую возможность 8.3.24 и как её можно эффективно использовать

27.06.2023    15551    SeiOkami    31    

103
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
121. hogik 443 12.09.13 01:54 Сейчас в теме
(120)
Андрей (Andreynikus).
Нет. Думаю, это не фильтры, а стереотипы.
Ну, скажите мне, пожалуйста, в какой еще СУБД (кроме MS SQL) возникнут в подобном алгоритме ("разделяемые" итоги) взаимоблокировки при использовании уровня изоляции "Read committed" ? И ведь многие привыкли, считают это нормальным поведением системы. А на самом деле это ... У меня слов нетУ. :-)
P.S.
Вот, прикрыл "проектик" по причине аналогичного "эффекта": http://infostart.ru/public/14664/
Но, разработчик этой сУБД хоть не говорили ничего про уровни изоляции. Т.к. там всё это очень "смазано" в смысле понятий/определений.
85. Andreynikus 1360 27.08.13 11:40 Сейчас в теме
Andreynikus, если вы хотите сказать, что суть установки управляемой блокировки по всем необходимым измерениям при установке свойства "БлокироватьДляИзменения" заключается в отключении разделения итогов, то - это бред. И вообще, такое понимание вопроса затуманивает суть.

Нет, суть конечно же в том что бы сделать блокировку по необходимым измерениям, отключение разделителя не самоцель а средство достижения этой цели :)

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

Если честно, я тут не вижу особой разницы, для меня смысл одинаковый
Установить блокировку без учета разделителя = отключить разделитель для данного набора
Можете выбрать любую правую или левую часть, как вам больше нравиться, здесь я спорить с вами не будут :) Главный смысл который я хотел донести, что разделитель не работает для записываемого набора значений, можете назвать это явление как вам будет угодно.

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

Узнал от разработчика платформы, но если вам нужны доказательства, то вот комментарий сотрудника фирмы 1С
Ключевая фраза Свойство БлокироватьДляИзменения, грубо говоря, просто отключает разделитель итогов для того, чтобы не возник дедлок
nalivai-chai; +1 Ответить
86. nalivai-chai 687 27.08.13 13:14 Сейчас в теме
(85) спасибо огромное.

Теперь всё встало на свои места.

Максим Радченко, сообщение 561730:
Свойство БлокироватьДляИзменения, грубо говоря, просто отключает разделитель итогов


Ключевая фраза "ГРУБО ГОВОРЯ" :). Вымучили из человека :).

Вопросов больше нет.

P.S. Но я бы не использвал понятие "отключает разделитель", фактически такого нет, разве что косвенно и "грубо говоря", это отвлекает от сути, вызывает ненужные вопросы.
CepeLLlka; hogik; +2 Ответить
87. ZLENKO 398 27.08.13 13:17 Сейчас в теме
Участники дискуссии пошли искать истину про то "что на самом деле делает" ...
Но я думаю интереснее было бы если бы кто то рассказал непосредственно свой опыт использования сабжа вместо теоретических изысканий :-) Например, я считаю что в случае версионной СУБД разделение итогов и, соответственно, использование данного свойства смысла не имеет. Ваше мнение по этому поводу ?
88. hogik 443 27.08.13 16:19 Сейчас в теме
(87)
"я считаю что в случае версионной СУБД разделение итогов и, соответственно, использование данного свойства смысла не имеет. "(с)

Владимир (ZLENKO.PRO).
А я считаю, что при наличии понятия итогов (любых) в схеме базы данных - не имеет смысла сама версионная СУБД. Т.к., в части работы с итогами, версионник ОБЯЗАН работать как блокировщик.
Это, типа, моё "теоретическое изыскание"... :-)
89. ZLENKO 398 27.08.13 17:04 Сейчас в теме
(88) hogik, не могу с Вами не согласится. В теории так оно и есть - при расчете итогов нужны блокировки. Однако на практике получается что смысл в версионной СУБД есть :-) Роль блокировшика по сути выполняет сервер приложений 1С и этого нам достаточно, а вот СУБД, работающая в режиме блокировщика накладывает избыточные блокировки и вызывает в лучшем случае ожидание на блокировках СУБД. Так что версионные СУБД "рулят" !

P.S.: Проверено электроникой :-)
90. hogik 443 27.08.13 17:15 Сейчас в теме
(88)
"Так что версионные СУБД "рулят" !"(с)

Владимир (ZLENKO.PRO).
Конечно - рулят. :-)
Только в других задачах, целях и алгоритмах: http://infostart.ru/public/157277/
Что касается избыточных блокировок в блокировщике, то имеет смысл вспоминать о других СУБД-блокировщиках. Которые не используют избыточных блокировок для решения собственных проблем с обеспечением уровней изоляции, как это делает "жестянка" MS SQL. :-)
91. ZLENKO 398 27.08.13 17:25 Сейчас в теме
Что касается избыточных блокировок в блокировщике, то имеет смысл вспоминать о других СУБД-блокировщиках

(90) Опять же в теории..., а на практике как часто Вы видели у заказчика "другие" СУБД-блокировщики и какие именно применительно к 1С ? :-)
92. hogik 443 27.08.13 17:32 Сейчас в теме
(91)
"Как часто Вы видели у заказчика "другие" СУБД"(с)
Владимир (ZLENKO.PRO).
Я и не смотрю, т.к. не работаю с 1С-продуктом... :-)
98. nalivai-chai 687 28.08.13 10:23 Сейчас в теме
(92) hogik, видел базы на PostreSQL и слышал от коллег, что встрачались с 1С на Oracle. Во всех случаях, на этих СУБД работали какие-то другие приложения и были соответствющие люди (админы БД), которые шарили в СУБД.

Все СУБД хороши. У всех есть свои плюсы и минусы.

MS SQL - выделятся тем, что она самая простая в использовании, установил и поехали, конечно в MS SQL куча настроек, но для новичков достаточно её поставить с настройками по умолчанию, чтобы все хоть как-то, но работало и с лучшими показателями, чем на файловой СУБД (естественно при многопользовательской работе).

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

Про "ораклу" много слышал, что отличная СУБД, только также много особенностей.
Andreynikus; +1 Ответить
93. ZLENKO 398 27.08.13 17:38 Сейчас в теме
(90) hogik, на практике нет реальной достойной альтернативы СУБД для 1С кроме как MS SQL уже даже по той простой причине что 1С всегда "затачивалась" под MS SQL и именно на ней работает наиболее эффективно. Для всех других СУБД нужны "танцы с бубном"...
94. hogik 443 27.08.13 18:10 Сейчас в теме
(93)
"нет реальной достойной альтернативы СУБД для 1С кроме как MS SQL"(с)
Владимир (ZLENKO.PRO).
Верю. :-)
Вы используете 1С с MS SQL в "версионном" режиме?
95. ZLENKO 398 27.08.13 23:46 Сейчас в теме
(94) Я использую файловый вариант 1С - для моих целей его достаточно :-)
97. ZLENKO 398 28.08.13 08:15 Сейчас в теме
(96) Вы же спросили про меня - я ответил. Мои заказчики используют, преимущественно, MS SQL Server 2008/R2.
К сожалению 1С в версии до 8.3 не сделала поддержку версионного режима для MS SQL. Не нужно думать что Вы "самый умный" - в этом нет ни смысла ни необходимости :-)
99. hogik 443 28.08.13 19:00 Сейчас в теме
(97)
"Не нужно думать что Вы "самый умный" - в этом нет ни смысла ни необходимости..."(с)

Владимир (ZLENKO.PRO).
Подобные фразы требуют пояснения, либо аналогичного ответа с моей стороны.
100. ZLENKO 398 28.08.13 22:26 Сейчас в теме
(99) Я имел ввиду что не нужно меня "шантажировать" моими высказываниями - не больше и не меньше этого. Ничего оскорбительного я не имел ввиду.
101. hogik 443 28.08.13 22:37 Сейчас в теме
(100)
Владимир (ZLENKO.PRO).
Это не "шантаж". Это попытка выяснить у Вас степень не "теоретических изысканий"(с) в Ваших высказываниях на тему про версионную СУБД. Вроде, я выяснил. :-)
Завершая беседу, дам краткий ответ на Ваш вопрос в (87) сообщении: Вы заблуждаетесь.
102. ZLENKO 398 29.08.13 00:31 Сейчас в теме
(101)
Вроде, я выяснил. :-)

Не имеет значения кто из нас двоих заблуждается :-) Ведь мы оба уверены в правильности своих рассуждений!
Вопрос в (97) является утверждением того что никто из участников дискуссии не может привести реальных аргументов опровергающих мое утверждение. Вобщем скучно здесь... :-(
103. hogik 443 29.08.13 02:15 Сейчас в теме
(102)
"никто из участников дискуссии не может привести реальных аргументов опровергающих мое утверждение."(с)
Владимир (ZLENKO.PRO).
А какие Вам нужны аргументы? :-)
Есть инструмент "разделяемые итоги", который позволяет для некоторых алгоритмов обеспечить каждой сессии (транзакции) свой набор уникальных записей. Ни одна сессия не претендует на обращение к записям другой сессии. Блокировки не требуются. Для "обычных итогов" несколько сессий имеют необходимость обратиться к одной записи. Требуется блокировка записи для последовательного обновления этой записи из разных сессий для любого "типа" СУБД.
А если Вы хотите веселья в теме, то подкрепите своё голословное утверждение описанием алгоритма работы с итогами в версионной СУБД. Думаю, мы все хором посмеёмся... :-)
104. ZLENKO 398 29.08.13 08:30 Сейчас в теме
(103) Оно конечно все так как Вы написали, но ровно до тех пор пока не будет обращения на чтение в версионной СУБД к разделенным итогам в рамках той же транзакции в которой произошла запись разделенных итогов. На этом моменте в Вашей "теории" и начнется настоящее веселье :-) потому как записи разделенных итогов других транзакций не попадут в версию данных в которой работает текущая транзакция. То есть оно конечно неважно если после записи регистров с разделенными итогами не читать итоги в той же транзакции... Как я уже писал (да и в 1С это уже хорошо понимают) что основная проблема с производительностью и масштабируемостью в 1С - длинные транзакции. Я нашел методику решения этой проблемы при помощи управляемых блокировок, версионной СУБД и так называемого "нового" метода контроля остатков - получил очень короткие транзакции только на время записи регистров. И что самое важное - эта методика легко применима в типовых конфигурациях 1С. Так что я эту задачку уже решил. Теперь можно смеяться :-)
106. hogik 443 29.08.13 16:42 Сейчас в теме
(104) (105)
Владимир (ZLENKO.PRO).
Полностью с Вами согласен. Однако, маленькое уточнение с моей стороны.
Я не разделяю идею "разделяемых итогов" 1С-разрабочиков... :-)
107. hogik 443 29.08.13 22:12 Сейчас в теме
(104)(105)
Владимир (ZLENKO.PRO).
Перечитал еще раз Ваши сообщения. Отменяю полное своё согласие. :-)
Опять Ваш странный вывод-связка:
"Определенный смысл в разделении итогов при использовании версионной СУБД есть"(с)
Ну, нет никаких значимых особенностей версионника при использовании "разделенных итогов" в сравнении с блокировщиком.
108. ZLENKO 398 29.08.13 23:27 Сейчас в теме
(107) Ну для Вас нет, а для меня есть. Это зависит от точки зрения и области применения. Жаль что больше никто так и не поддержал нашу дискуссию :-(
109. hogik 443 29.08.13 23:41 Сейчас в теме
(108)
"Ну для Вас нет, а для меня есть."(с)
Владимир (ZLENKO.PRO).
Разговор не про наши с Вами особенности, а про особенности версионника. :-)
Если они есть - опишите их...
110. ZLENKO 398 30.08.13 08:07 Сейчас в теме
(109) Ну я же уже писал выше про практическую разницу использования разделения итогов. При чтении данных из регистра после записи данных в регистр при наличии нескольких одновременных пишущих и читающих транзакций в случае блокировщика получим деадлок (для меня это очень плохо), а в случае версионника получим данные без учета записанных данных других транзакций (для меня это тоже плохо). Поэтому использовать разделение итогов имеет смысл и версионнике, но при полной уверенности что данные не будут читаться после записи. Вроде бы все просто и понятно, но давайте посмотрим, например, на регистр плана счетов (а вот для него реально имеет очень большой смысл разделение итогов) и конфигурацию Управление производственным предприятием - ну невозможно обеспечить отсутствие чтения этого регистра после записи. Я достаточно понятно описал особенности версионника и почему они для меня имеют значение ?

P.S.: Просто получается что есть куча всяких фишечек (типа управляемые блокировки, возможность не стирать данные в регистрах при перепроведении и т.п.) и теоретически можно создать "идеально" работающую конфигурацию. Но критерии идеальности у разных людей разные, а реально есть реальные конфигурации в которые нужно "приблизить" к этому идеалу. Именно этим вопросом я занимался несколько месяцев назад: как с минимальными изменениями реальную конфигурацию сделать идеальной с точки зрения параллельности работы и получить запас масштабируемости. Нашелся всего один реальный вариант решения в виде комбинации этих "фишечек", в том числе необходима СУБД версионник.
111. nalivai-chai 687 30.08.13 12:05 Сейчас в теме
(110) ZLENKO.PRO, использование разделения итогов имеет смысл вне зависимости от того, что БД находится в версионном режиме или нет, т.к. использование разделения влияет на поведение блокировщика сервера 1С.

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

Версионник дает широкие возможности, но при этом нужно быть значительно аккуратнее с управляемыми блокировками, т.к. в неверсионнике иногда сама БД может подсказать своей блокировкой, что где-то и что-то упущено.
114. ZLENKO 398 30.08.13 18:43 Сейчас в теме
(111) "Версионник дает широкие возможности, но при этом нужно быть значительно аккуратнее с управляемыми блокировками, т.к. в неверсионнике иногда сама БД может подсказать своей блокировкой, что где-то и что-то упущено."
Так и я о том же пишу... Никто не в состоянии прокрутить в голове весь код конфигурации УПП и прикинуть что же где там "упущено" - где писать БлокироватьДляИзменения а где не писать. А в теории (112) то оно все правильно "Если требуется - блокируем, если не требуется не блокируем".
Вернемся к моему первоначальному вопросу "Кто на практике в реальной конфигурации БлокироватьДляИзменения использовал ?"
116. hogik 443 30.08.13 19:09 Сейчас в теме
(114)

"Как я уже писал, проблему поиска оптимального решения максимально возможного уменьшения количества блокировок в реальных 1С конфигурациях мной уже решена - зачем мне еще что то читать ?"©
"Вернемся к моему первоначальному вопросу "Кто на практике в реальной конфигурации БлокироватьДляИзменения использовал ?"©


Владимир (ZLENKO.PRO).
Интересная логика. Вы, наверно, программистом работаете. :-)
117. ZLENKO 398 30.08.13 22:45 Сейчас в теме
(116) Кем я только не работал ... :-) Ну и программистом тоже подрабатываю :-)
112. hogik 443 30.08.13 17:16 Сейчас в теме
(110)
"имеет смысл и версионнике, но при полной уверенности что данные не будут читаться после записи."(с)
"ну невозможно обеспечить отсутствие чтения этого регистра после записи"(с)

Владимир (ZLENKO.PRO).
Может Вы не посмотрели новую версию данной публикации после моей беседы с автором? :-)
Еще раз повторю:
1) Если требуется чтение при "разделённых итогах" после записи, то для обоих "типов" СУБД требуется блокировка "абстрактного" ресурса. Что может вызывать взаимоблокировки, например, при проведении многострочных документов.
2) Если требуется изменение "обычного итога" (с последующим чтением или без чтения), то для обоих "типов" СУБД требуется блокировка "реального" ресурса. Что может вызывать взаимоблокировки, например, при проведении многострочных документов.
3) Если не требуется чтение при "разделенных итогах", то не требуется никаких блокировок при записи для обоих "типов" СУБД. И если сама СУБД (любая!!!) наложит блокировки на записи "разделенных итогов", то никаких взаимоблокировок не произойдет.
4) Если требуется чтение при "разделенных итогах" без предыдущей записи (например, в отчетах), то для обоих "типов" СУБД требуется блокировка абстрактного ресурса.
5) Если требуется чтение при "обычных итогах" без предыдущей записи (например, в отчетах), то для обоих "типов" СУБД не требуется блокировка. Это, естественно, если не требуется согласованной информации уже на уровне итогов различных регистров и/или обработки итоговой записи с учетом движения соответствующего регистра. А если требуется, то смотрите публикацию от уважаемого Тарасенкова Александра (ссылку выше по теме уже давал).

Вот и всё сложности/особенности... :-)
113. ZLENKO 398 30.08.13 18:35 Сейчас в теме
(112) Вы же сами утверждали что нет никаких особенностей :-) Я уже писал что мы смотрим на самом деле одинаково на одно и то же но с разных точек зрения. Вот Вы тут пишете "Если требуется ...", а я думаю о том что "ну вот есть у меня конфа (скажем УПП или КА) - что нужно сделать в ней с минимальными затратами чтобы работало быстрее?" И я бы не против использовать разделение итогов для регистра плана счетов в версионной СУБД если бы при этом клиенты 1С не падали :-) С теорией темы топика я давно уже разобрался, да и с практикой тоже :-) Как я уже писал, проблему поиска оптимального решения максимально возможного уменьшения количества блокировок в реальных 1С конфигурациях мной уже решена - зачем мне еще что то читать ?
115. hogik 443 30.08.13 19:02 Сейчас в теме
(113)
Владимир (ZLENKO.PRO).
ВладИИИИИИИИИИИИИИИмир. :-)
Я пишу, что "нет никаких особенностей"(с) при использовании инструмента "разделенных итогов" в любом "типе" СУБД. Ключевое слово - ЛЮБАЯ. А в самом инструменте, естественно, есть особенности. Данный инструмент малоприменим в реальных (сложных) алгоритмах обработки информации. Лично, я от использования подобной идеи (инструмента) отказался лет двадцать тому назад. ;-) Хотя, при первом взгляде было ощущение - вот оно счастье избежать взаимоблокировок при наличии итогов в схеме базы данных. :-)
105. ZLENKO 398 29.08.13 08:50 Сейчас в теме
Пожалуй уточню свое высказывание в (87). Определенный смысл в разделении итогов при использовании версионной СУБД есть, но в рамках типовых конфигураций от 1С сложно предусмотреть отсутствие обращения на чтение после записи регистров в той же транзакции (регистры пишутся по нескольку раз явно в процессе проведения), а уж в "доработанных" конфигурациях такое сплошь и рядом. Поэтому мое высказывание было основано "на реальных событиях", а в "теории" конечно пусть будет разделение итогов и в версионных СУБД. Просто основная часть людей вообще не задается теми вопросами которые мы тут обсуждаем - включат разделение итогов в конфигурации с новой методикой контроля остатков в версионной СУБД и будут ломать мозг почему их контроль остатков "глючит", а вот деадлок в случае блокировщика они скорее всего даже не заметят. Вобщем в "теории" Вы правы, "на практике" я прав. У каждого своя "правда", а истина непостижима (с) из курса философии.
122. headMade 144 22.11.13 01:05 Сейчас в теме
Хотел уточнить, а в "старо
123. headMade 144 22.11.13 01:11 Сейчас в теме
Хотел уточнить, а в "старой схеме" контроля остатков при удалении предыдущих движений документа

// Удаление предыдущих движений документа
Движения.ОстаткиНоменклатуры.Записать();

// Блокировка данных
Блокировка = Новый БлокировкаДанных;

т.е. перед строкой "Движения.ОстаткиНоменклатуры.Записать();" надо или нет устанавливать св-во "БлокироватьДляИзменения"?

Спасибо.
124. Andreynikus 1360 24.11.13 23:17 Сейчас в теме
(123) headMade,
В этом случае нужно ставить БлокироватьДляИзменения=Истина, иначе возможна взаимоблокировка.
Но тут вопрос в другом, зачем вообще для такого регистра включен разделитель?
Ведь если используется "старая" методика проверки остатков, то включение разделителя итогов не имеет никакого смысла.
125. Slon1c 09.01.14 18:37 Сейчас в теме
(124) где там взаимоблокировка ? Вопрос в неправильном списании остатков.
127. Patrio_O_Muerte 18.02.17 20:17 Сейчас в теме
Добрый день.

При использовании СУБД блокировочника - возможна взаимоблокировка.
При использовании версионника - возможно списание остатков в минус.

Я вот чего не пойму - в какой момент, каким образом и кто решает - какой механизм будет использован - версионник или блокировочник.
128. Andreynikus 1360 18.02.17 23:45 Сейчас в теме
(127)
Это зависит от СУБД и от ряда настроек
Версионниками являются СУБД PostgreSQL или Oracle.
DB2 и MS SQL Server являются блокировочниками хотя сейчас уже не все так однозначно.
MS SQL Server тоже может работать как версионник начиная с версии 2005. Если использовать платформу 8.3 и MS SQL Server то эта связка будет работать как версионник.
129. nytlenc 15.08.17 09:02 Сейчас в теме
1. Данное свойство нужно использовать, только если соблюдаются все 3 условия:
- транзакция выполняется в управляемом режиме
- у регистра включен режим разделения итогов
- используется новая методика контроля остатов (остатки контролируются после записи)

Не согласен. Новая методика контроля остатков (кстати она правильно называется методика оперативного проведения) тут совсем не причем.
БлокироватьДляИзменения накладывает управляемую блокировку (система сама определяет пространство блокировки и т.д. на основании уже созданных движений).
Представьте вы провели документ. Остатки при проведении вообще не контролируются. Например это приходная накладная. И если это новый документ, тогда БлокировтьДляИзменения не имеет смысла. Но вот документ проведен. Движения сформированы и тут пользователь заходит в документ и вообще меняет его, указывает другую номенклатуру, другую партию, количество и т.д. и снова его проводит. Что будет если у Вас БлокироватьДляИзменения будет ЛОЖЬ? А ничего хорошего не получится, в момент пока проводится эта накладная, кто то спишет товары, и если по каким то причинам эта приходная не проведется будет * транзакции в рещультате чего у Вас нарисуется минус в регистрах.
132. Andreynikus 1360 16.08.17 20:52 Сейчас в теме
(129)
Что будет если у Вас БлокироватьДляИзменения будет ЛОЖЬ? А ничего хорошего не получится, в момент пока проводится эта накладная, кто то спишет товары, и если по каким то причинам эта приходная не проведется будет * транзакции в рещультате чего у Вас нарисуется минус в регистрах.


Это распространенное заблуждение, которе происходит от непонимания работы платформы и механизма блокировок. Проведите опыт самостоятельно с точкой останова в отладчике и убедитесь.
130. nytlenc 15.08.17 09:35 Сейчас в теме
Прошу прощения. Будет произведена отмена транзакции в результате чего у Вас нарисуется минус в регистрах. (почему то на форму слово от_кат заменяется на звездочку)
133. Andreynikus 1360 16.08.17 20:53 Сейчас в теме
(130)
Если вы распроведете приход, то минус будет в любом случае, независимо от данного свойства.
144. user107915 03.01.20 07:23 Сейчас в теме
"блокирвоку" исправьте
145. Froloid 66 16.03.23 13:51 Сейчас в теме
Данное свойство нужно использовать только если у вас низконагуженная или "тупая" база. А так - если у вас высоко нагруженная база и вы перешли с ерп 2.4 на 2.5, где начали использовать до свойство вместо явных управляемых блокировок (в моём случае 2.5.8 - возможно не всегда в 2.5 так было), то вам теперь нужно оперативно переписывать весь этот бред обратно на явные управляемые. А пока вы это делаете - виновато смотреть в глаза пользователям загибающимся от таймаутов привнесённых необдуманным использованием данного свойства.
146. Andreynikus 1360 16.03.23 13:56 Сейчас в теме
(145)
Необдуманное использование чего угодно ни к чему хорошему не приводит :)
Можете пояснить как именно у вас включение данного свойства привело к таймаутам?

Как оно может приводить к дедлокам я могу понять, но вот таймауты это что-то новое.
147. Froloid 66 16.03.23 18:58 Сейчас в теме
С необдуманным - всё понятно. Жаль только, что это со стороны разработчиков флагманского решения произошло и успешно продолжает жить.

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

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

И в итоге система работает по принципу - контроль остатков я произвожу по изменённым 3-м строкам, а блокирую все 100. Ведь "теперь не нужно вручную накладывать управляемую блокировку и это так здорово".
148. Froloid 66 16.03.23 19:01 Сейчас в теме
(147) А если ещё учесть, как чудовищно понизилась скорость проведения документов с "большими" табличными частями из-за гениального решения по "распределению запасов", то количество таймаутов возросло примерно в 10 раз. Но зато работы теперь - непочатый край. Есть где разгуляться экспертам по технологическим вопросам.
150. Andreynikus 1360 17.03.23 06:23 Сейчас в теме
(148)
Ну это старая тактика 1С уж не знаю сознательная или нет.
Сначала создать проблемы, а потом героически их решать, за деньги клиента естественно ))
149. Andreynikus 1360 17.03.23 06:04 Сейчас в теме
(147)
Если я правильно понял, то раньше набор записей движений формировался вручную только из измененных строк, а теперь алгоритм изменился?
Если так, то "БлокироватьДляИзменения" тут не причем, он лишь ставит сплиттер для набора записей, а уж как именно вы его формировали не его ответственность.

Сейчас специально попробовал провести опыт, с включенным разделителем и без.
Если менять реквизит документа который не влияет на движения, то блокировки по пространству DIMS не происходит, не важно включен разделитель или нет.
Если изменить количество в любой строке, то блокируются все записи набора, не зависимо от того включен разделитель или нет. Это если движения формируются стандартно, без ручного вмешательства.

Можете описать опыт который можно воспроизвести на тестовой базе что бы показать что не измененные строки не блокируются, но блокируются если включено свойство?
151. triviumfan 91 19.04.23 09:46 Сейчас в теме
(149) Очуметь, Андрей до сих пор отвечает в своей статье спустя 10 лет! Вот это сервис!
Жаль, что больше не пишет статей :( Может курсы до сих пор проводит?
152. Andreynikus 1360 19.04.23 14:09 Сейчас в теме
(151)
Спасибо на добром слове, ну комментарий то оставить не сложно, этож не статью написать ))
Курсы вживую уже давно не веду.
Оставьте свое сообщение