Если прочитать методику перевода конфигурации на управляемые блокировки от 1С - можно там найти много всего интересного и пугающего. На самом деле всё просто: В свойствах конфигурации меняете режим блокировки данных - "Управляемый". Всё. Могу вас поздравить - вы только что перешли на управляемые блокировки. На самом деле всё несколько сложнее - но не на много.
Для начала небольшой теоретический экскурс - зачем нужны блокировки: У кого есть доступ конечно можно прочитать здесь: http://kb.1c.ru/articleView.jsp?id=30 1С озаботились написать достаточно доступную статью про блокировки данных. У кого же доступа нет в двух словах опишу для чего нужны блокировки:
Пример 1. Если после включения управляемых блокировок ничего не делать, и при этом начать параллельно проводить 2 документа (один из них ведь всё равно на долю секунды раньше), то получим приблизительно следующую картину:
Транзакция 1
Транзакция 2
Состояние остатков
Начало
|
1 шт
|
Начало
1 шт
|
|
1 шт
Чтение остатков
|
1 шт
|
Чтение остатков
1 шт
|
|
1 шт
Списание с остатков
|
0 шт
|
Списание остатков
-1 шт
Завершение
|
Завершение
Что здесь не так? Контроль остатков дал сбой. 2-ой документ успел прочитать остатки раньше, чем 1-й успел их записать. При этом увидел, что на остатках 1 штука и спокойно списал их вслед за первым. Стоит оговориться, что по факту блокировки здесь всё-таки будут. 2 документа не смогут списать остатки одновременно, это необходимо для логической целостности БД, но для решения прикладной задачи в данном примере вряд ли полезно.
Теперь постараемся исправить ситуацию - в коде проведения документа пропишем установку эксклюзивной управляемой блокировки непосредственно перед чтением остатков:
Транзакция 1
Транзакция 2
Состояние остатков
Начало
|
1 шт
|
Начало
1 шт
Блокировка
|
1 шт
Чтение остатков
|
1 шт
|
Попытка блокировки
1 шт
|
Ожидание на блокировке
1 шт
Списание с остатков
Ожидание на блокировке
0 шт
|
Ожидание на блокировке
0 шт
Завершение
Ожидание на блокировке
0 шт
Блокировка
0 шт
Чтение остатков
0 шт
|
0 шт
Отказ
0 шт
При этом 1-я транзакция блокировку успеет установить, а вторая попытается установить блокировку и будет ждать освобождения ресурса, до тех пор пока не завершится 1-я транзакиця. Стоит отметить, что блокировки действуют только до завршения транзакции, и, естественно, блокировки блокируют ресурс только для изменения из других сессий. Всё логично, но паразительно как много людей об этом не знают.
Ну теперь, когда разобрались зачем блокировки нужны остаётся только установить управляемые блокировки там где это нужно: а именно -только там где производится контроль остатков. Если у вас в базе менеджер имеет право провести документ вне зависимости от того есть товар(деньги) на остатках или нет, зачем вам тогда блокировки? Можете их просто не устанавливать, или прописать и закомментировать до лучших времён. Если же у вас производится контроль остатков то как правило это 3-4 регистра, ну максимум 10-ок. Контроль можно подвесить как в общие процедуры и функции, так и в модули набора записей РН. Код предельно простой, открываем синтаксис помошник - смотрим:
Блокировка = Новый БлокировкаДанных;
ЭлементБлокировки = Блокировка.Добавить("РегистрНакопления.ТоварыНаСкладах");
ЭлементБлокировки.УстановитьЗначение("Качество", Справочники.Качество.НайтиПоКоду("1"));
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
ЭлементБлокировки.ИсточникДанных = ДокументОбъект.ВозвратнаяТара;
ЭлементБлокировки.ИспользоватьИзИсточникаДанных("Номенклатура", "Номенклатура");
ЭлементБлокировки.ИспользоватьИзИсточникаДанных("Склад", "Склад");
Блокировка.Заблокировать();
Собственно всё сразу понятно - блокируем "товары на складх", 1 измерение становим в явном виде, значения 2-х других возьмём из источника данных - ТЧ документа.
Те кто читал книжки по 8.2 наверное помнят о "Новой логике проведения" - когда контроль остатков производится после записи движений документа. Задвались вопросом зачем это? А вот эту же табличку перерисуем так что контоль остатков и блокировка будут после записи движений:
Транзакция 1
Транзакция 2
Состояние остатков
Начало
|
1 шт
|
Начало
1 шт
|
|
1 шт
Списание с остатков
|
0 шт
|
Списание с остатков
-1 шт
Блокировка
|
-1 шт
Чтение остатков
Попытка блокировки
-1 шт
|
Ожидание на блокировке
-1 шт
|
Ожидание на блокировке
-1 шт
Завершение
Ожидание на блокировке
-1 шт
Блокировка
-1 шт
Чтение остатков
-1 шт
|
-1 шт
Отказ
0 шт
Разница с виду не значительная - прирост производительности получаем за счет того что на время списания остатков (запись их в базу, что, собственно занимает время) блокировки ещё нет. Блокировка возникает позже к концу транзакции, куда вынесен контроль отрицательных остатков, бизнес логике приложения это вполне удовлетворяет.
Зная для чего блокировки нужны можно действительно ими управлять исходя из бизнес задач которые вы решаете. СУБД разрабатываются исходя из предположения обеспечения максисальной защиты данных. В случае если вы, к примеру, осуществляете банковские транзакции блокировки должны быть везде и на максимальном уровне. Лучше заблокировать лишние записи, чем допустить противоречивость данных.
В случае же если вы продаёте булочки или шариковые ручки, на вряд ли вам нужно столь много блокировок. Браком и пересортом по человеческой вине вы теряете в сотни раз больше, чем могли бы в случае одновременного проведения двумя пользователеями двух одинаковых докуметов отгрузки.
Для варьирования между такими разными задачами в СУБД придумали уровни изоляции. Устанавливая уровень изоляции транзакций можно сказать СУБД какие блокировки накладывать в разных случаях (при записи и при чтении в транзакции) в разных случаях накладываются S (можно читать нельзя писать) или X (нельзя ни читать ни писать) блокировки.
Так в автоматическом режиме у вас почти всегда будет уровень изоляции SERIALIZABLE, который будет накладывать X блокировки где нужно и где не нужно, что будет существенно портить вам жизнь
А в управляемом у вас будет READ COMMITED, который будет накладывать и тут же снимать S блокировку при чтении, и X только при записи. Самый хитрый уровень. Быстро накладываемая S блокировка как раз позволяет проверить не наложена ли где на эти данные X блокировка, что и обеспечивает чтение только согласованных данных, как принято для данного уровня изоляции, а в случае если вы прочитали и выполнили действя, рекоммендованные в предыдущей статье, то не будет даже S блокировки при чтении, таким образом на уровне СУБД будет блокироваться только запись во время записи - что правильно и необходимо для сограсованности данных.
Как же вы поступите с управляемыми блокировками - только ваше решение. Но я бы рекоммендовал не торопиться их устанавливать. Я встречал компании в которых был автоматический режим блокировки, при этом слово "замучали блокировки" звучало даже из уст генерального директора, и при этом был отключен контроль отрицательных остатков....
Для чего нужны блокировки
Разработка - Механизмы платформы 1С
См. также
Сервисы интеграции без Шины и интеграции
Механизмы платформы 1С Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)
Пример использования «Сервисов интеграции» без подключения к Шине и без обменов.
13.03.2024 2683 dsdred 16
Поинтегрируем: сервисы интеграции – новый стандарт или просто коннектор?
Обмен между базами 1C Администрирование СУБД Механизмы платформы 1С Платформа 1С v8.3 Бесплатно (free)
В платформе 8.3.17 появился замечательный механизм «Сервисы интеграции». Многие считают, что это просто коннектор 1С:Шины. Так ли это?
11.03.2024 6209 dsdred 59
Как готовить и есть массивы
Механизмы платформы 1С Платформа 1С v8.3 Бесплатно (free)
Все мы используем массивы в своем коде. Это один из первых объектов, который дают ученикам при прохождении обучения программированию. Но умеем ли мы ими пользоваться? В этой статье я хочу показать все методы массива, а также некоторые фишки в работе с массивами.
24.01.2024 6078 YA_418728146 25
Планы обмена VS История данных
Обмен между базами 1C Механизмы платформы 1С Платформа 1С v8.3 Бесплатно (free)
Вы все еще регистрируете изменения только на Планах обмена и Регистрах сведений?
11.12.2023 7155 dsdred 36
1С-ная магия
Механизмы платформы 1С Бесплатно (free)
Язык программирования 1С содержит много нюансов и особенностей, которые могут приводить к неожиданным для разработчика результатам. Сталкиваясь с ними, программист начинает лучше понимать логику платформы, а значит, быстрее выявлять ошибки и видеть потенциальные узкие места своего кода там, где позже можно было бы ещё долго медитировать с отладчиком в поисках источника проблемы. Мы рассмотрим разные примеры поведения кода 1С. Разберём результаты выполнения и ответим на вопросы «Почему?», «Как же так?» и «Зачем нам это знать?».
06.10.2023 19267 SeiOkami 46
Дефрагментация и реиндексация после перехода на платформу 8.3.22
Механизмы платформы 1С Платформа 1С v8.3 Бесплатно (free)
Начиная с версии платформы 8.3.22 1С снимает стандартные блокировки БД на уровне страниц. Делаем рабочий скрипт, как раньше.
14.09.2023 12985 human_new 27
Валидация JSON через XDTO (включая массивы)
WEB-интеграция Универсальные функции Механизмы платформы 1С Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)
При работе с интеграциями рано или поздно придется столкнуться с получением JSON файлов. И, конечно же, жизнь заставит проверять файлы перед тем, как записывать данные в БД.
28.08.2023 9589 YA_418728146 6
Внешние компоненты Native API на языке Rust - Просто!
Механизмы платформы 1С Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)
Внешние компоненты для 1С можно разработывать очень просто, пользуясь всеми преимуществами языка Rust - от безопасности и кроссплатформенности до удобного менеджера библиотек.
20.08.2023 6591 sebekerga 54
Т.е. Вы не способны ответить на простой вопрос?
Или не способны прочесть (68) сообщение?
Там написано: "Началось всё в 2000 году...".
Вы в курсе, что тогда еще не было "восьмерки"? :-)
Или Вы считаете, что на "семерке" (без её доработки) можно иметь нечто большее чем примитивную однопользовательскую учетную систему бумажных документов?
Если вы так хорошо доработали файловый вариант под 30 пользователей, зачем понадобился SQL?
Если все завершилось установкой SQL, зачем надо было изобретать велосипед и убивать время на доработку файловой версии?
"все завершилось установкой SQL"(с)
А почему Вы сделали такой вывод?
Т.е. Вы считаете, что "клиент-серверную СУБД"="SQL" ?
Это "типичное" заблуждение, подпитываемое жадными дядями - изготовителями "запросных", реляционных СУБД. :-)
Если я правильно понял суть вопроса, то Вы блокируете только те регистры которые связаны с остатками... остальные объекты остаются без контроля... Тогда простой пример: 2 человека пишут один и тот же документ\справочник\и т.д. с разными данными, который не относится к остаткам...хм.. что в итоге получится я не представляю... нет никаких гарантий целостности данных.
Далее пример: мы пишем приходник он к остаткам не имеет отношения, но двигает взаиморасчетам, по которым тоже необходимо вести контроль(например) и в итоге проводится реализация которая превысила долг контрагента... то есть надо еще настраивать блокировки и на взаиморасчеты... в итоге получается что для нормальной настройки базы необходимо проделать огромный труд!
Еще раз повторюсь, что не все так просто!!!
P.S. возможно маленькая вероятность возникновения конфликтных ситуаций в базе, но эта вероятность зависит от очень многих факторов. И нет никакой гарантии что она не возникнет в самый неподходящий момент.
1) Если 2 человека пишут один и тот же документ/справочник - существуют "объектные" блокировки на уровне платформы :), от которых ну никак не избавишься
2) Целостность данных поддерживается на уровне СУБД - естественно при записи данные блокируются, об этом уже писал выше в комментах - почитайте
3) Ну да, если хотите чтобы "-" не мог возникнуть то нужно ставить блокировку при чтении взаиморасчетов. Но это не огромная работа. Сколько вы ещё знаете таких примеров. В УТ 11 по-моему блокируются как раз только товары на складах и взаиморасчеты... и всё - 10 строчек кода :)
3. Но проблема все равно не уходит:
Я знаю что надо контролировать: остатки, взаиморасчеты + контроль числа дней задолженности, остатки по партиям и еще много чего, лень вспоминать.
Все это надо обдумать как делать ведь, как я понимаю суть вашего примера в том что блокируется на чтение регистр до момента завершения записи этого регистра (а не до конца записи всех данных документа, иначе это была бы почти обычная блокировка как сечас), потом освобождается.
В этот момент и может произойти путаница: Пример(упрощенный чисто для примера конфликта):
1. Реализация1 блокировка остатков, контроль пройден успешно.Запись
2. Реализация2 блокировка остатков, контроль не пройден из за списания Реализации 1. Отмена проведения.
3. Реализация1 блокировка взаиморасчетов, контроль не пройден. Отмена проведения.
....
В этом примере Реализация 2 должна была быть проведена.
То есть надо блокировать до конца записи всего документа но это шило на мыло, или переделывать проведение документа, сначала двигать "важные" регистры и блочить до конца их записи.
P.S. ну в общем и целом это здоровая оптимизация, только ИМХО надо очень хорошенько все продумать, и поработать(все еще остаюсь при своем мнении что это большой труд)!
Алексей (a-novoselov).
Вы не "попытались доказать"(с), а изложили НЕЧТО:
1) "блокировки только на чтение данных,"(с) - допускаю.
2) "прочитали - заблокировали - начали что-то писать."(с) - странно.
3) "другая транзакция не сможет прочитать те же данные"(с) - легко!!!
Для успешного выполнения утверждения #3, требуется в #2 сначала заблокировать, а потом читать. ;-)
"это условие вовсе не обязательное, если нет контроля остатков"(с)
Алексей (a-novoselov).
Контроль остатков (итогов) есть ВСЕГДА. А "проверка отрицательности" может и не быть. И весь вопрос ГДЕ, КАК, КТО, КОГДА, ПОЧЕМУ требуется, именно, КОНТРОЛЬ, а не ПРОВЕРКА.
(97)
"Мне, я думаю, вас не о чем спрашивать"(с)
Олег.
Вы напрасно тратите свое время и силы на доказательство моей глупости. Я уже признался, что я полный идиот и ничего не понимаю. Как начал разрабатывать ИС+СУБД в начале 70-х годов так ничего и нЭпонимаю... :-) А больше всего, я нЭпонимаю - за ЧТО мне, все эти годы, платят деньги. :-)
Табличку, то нарисуйте...
Ведь данную тему не только мы с Вами читаем!!!
Вы, вроде, статью написали, а не оправились в блоге?
По поводу "запросных" СУБД:
P.S.
У меня к Вам предложение. ;-)
Давайте поменяем аннотации к Вашим статьям на, примерно, такой текст:
"Если Вы, случайно, купили "1С 8.х" вместо текстового редактора и ОНА мешает Вам работать своими блокировками. То Я сейчас Вас научу как ЕЁ превратить в текстовый редактор".
Олег.
Я призываю Вас перестать доказывать мою глупость. Доказывайте, пожалуйста, свою "умность". Таблички у Вас Не"адекватные" и с ошибками. Еще раз - приведите табличку описанную в моём (89) сообщении. Мы с Вами занимаемся бла-бла уже две недели. Пора закругляться...
Олег.
1) "комментирующий чужую статью"(с)
Я не комментирую Вашу статью, а задаю вопросы автору. Содержательных ответов - не получаю. И вопросы задаю, не для ответов с Вашей стороны, а для Вашего полного осознания того, что Вы написали. Вам это, видимо, не требуется. Т.к. для Вас и СУБД растут на полках магазинов.
2) "Это как бы классика жанра :). Года 3 назад появилась "(с)
Т.е. в комментарии (5) написано верно? Тогда Ваша фраза "1С озаботились написать достаточно доступную статью про блокировки данных"(с) - удивительное хамство в адрес разработчиков 1С !!!
3) "Рад за вас что наконец то прочитали"(с)
В этой статье ничего нового, для меня, не написано. Это один из способов реализовать решение проблемы "документ-запрос-итоги". Именно - только реализовать!!! Сам способ - очевиден. В частности это обуславливает появление т.н. "сервера приложений" при использовании СУБД с "запросным" (например - SQL) ЯМД (кратко звучит как - "запросные" СУБД). Разработчикам 1С-а остаётся еще реализовать "логическую" транзакцию силами "сервера приложений" и тогда они смогут устранить основные недостатки подобных СУБД. :-) Об ЭТОМ думает, пишет, делает и т.д. - "весь Мир". И выбирает более "дешевые" для пользователя (!!!) решения, чем это делают разработчики 1С-ов.
Сама "суть-проблема" появилась очень давно, но "обострилась" с появлением "интерактивных" ИС-ов.
Вы выбрали (предложили) самый дешевый способ - иметь "бардак" в интерактивных "задачах" и наводить порядок позже в "пакетном" режиме. Это сильно согласуется с "концепциям" продуктов 1С-разработчиков. ;-) Но ЭТО было УЖЕ сделано лет 40 тому назад...
P.S. Ссылки на первоисточники, я "публиковал" в данном обсуждении для подкрепления (прояснения) сути своих вопросов для нашего с Вами понимание о ЧЕМ мы говорим. А по своему роду деятельности такие материалы стараюсь изучать по мере их появления, в ожидании появления в продуктах от 1С "логической транзакции"... :-)
(104)
"Вмешаться не смог"(с)
Игорь.
Зря! Тема - наша с Вами: "Мы пишем з...". Помню Вы мне написали (спросили):
"Можно , конечно, порассуждать о видах блокировок . Но я скромно спрошу : а при чём тут задача просроченных долгов ?"(с) [декабрь 2009 года]
И, хотя, тогда о блокировка я упомянул не в контексте "видов" блокировок, а контексте "возможности" их использования (типа, ближе к теме
Но зря мы не поговорили тогда о "видах". ;-) Вот сейчас пытаемся поговорить. Тщетно... :-(
(0)
Р.P.P.....S.
Олег.
Моё личное мнение - у Вас лучше получается писать об "УУ" в части "как ЭТО должно быть сделано на бумаге". А что касается ИС в части ЕГО воплощения в ЭВМ-ах - лучше не писать. Не знаю может МЫ не доросли до "УУ" по смыслу, но точно знаю - по его АвтоМехАнизации НАМ еще нужно очень долго расти. Т.к. именно в "УУ" требуется "оперативность И точность". А не ИЛИ. И для этого НАМ надо научиться (понимать) зачем ОНИ придумали БД (банк данных) и как с БД (база данных) должна работать СУБД.
Вот...(с)
Всем спасибо за внимание.
Игорь.
Эх, ну и "заноза" Вы... ;-)
Включаем режим - "узко-конкретно"(с).
Попытаюсь излагать в терминах 1С.
Разделяемые итого не рассматриваем.
Связь с другими видами документов и регистров не рассматриваем. Т.к. вопрос перевода всей конфигурации на управляемые блокировки не является ключевым моментом публикации.
Общие условия:
1) Управляемые блокировки.
2) Документ - одна транзакция.
3) Одна строка документа образует одну строку движения в одном регистре накопления.
4) Оперативное проведение.
Вариант #1: Отключено использования текущих итогов.
=== Проверка отрицательности итога не имеет смысла. Тема обсуждения закрыта. ;-)
Вариант #2: Включено использования текущих итогов, но проверка отрицательности не требуется.
Вариант #2.1: Не интересует корректность итогов.
=== Надо использовать Вариант #1.
Вариант #2.2: Требуется обеспечить корректность итогов.
=== Блокировки итогов должны быть установлены на все время жизни транзакции.
Вариант #3: Требуется проверка отрицательности итогов.
=== Необходимо использовать рекомендации из:
Автор темы утверждает, что если не требуется контроля отрицательности, то надо выбросить блокировку итогов, т.е. Вариант 2.1. Т.е. движения по каждой строке документа записываются, фиксируются и откатываются всегда корректно. А корректность актуальных итогов нас не интересует. Тогда какой смысл их, вообще, обновлять при проведении - нагружать систему лишней работой. Т.е. должнО использовать Вариант #1. А при этом варианте в модуле проведения, вообще, нет строк алгоритма проверки отрицательности. Т.е. нет предмета для обсуждения...
или
P.S на вопросы к автору как и обещал отвечаю:
Олег.
Даю информацию по появлению жаргонного (в среда СУБД-шников) выражения: "запросные" СУБД.
Если чего будет не понятно - спрашиваете. ;-)
1) "Важно подчеркнуть, что для разработчиков и пользователей СУБД точным определением реализованной в ней модели данных являются фактически языковые средства определения данных и манипулирования данными, воплощающие функциональность этой модели. Действительно, базовая реляционная модель Кодда (материализованная в языке ALPHA) – совсем иная модель данных, чем реляционная модель, воплощенная в языке SQL, или RM/T. По этой причине существует целое семейство возможных реляционных моделей данных и имеются различные конкретные его представители."(с)
[Абстракции и модели в системах баз данных. М. Р. Когаловский. 01.08.1998]
1) "В классической теории баз данных, модель данных есть формальная теория представления и обработки данных в системе управления базами данных (СУБД), которая включает, по меньшей мере, три аспекта:
а) аспект структуры: методы описания типов и логических структур данных в базе данных;
б) аспект манипуляции: методы манипулирования данными;
в) аспект целостности: методы описания и поддержки целостности базы данных.
Аспект структуры определяет, что из себя логически представляет база данных, аспект манипуляции определяет способы перехода между состояниями базы данных (то есть способы модификации данных) и способы извлечения данных из базы данных, аспект целостности определяет средства описаний корректных состояний базы данных.
Модель данных — это абстрактное, самодостаточное, логическое определение объектов, операторов и прочих элементов, в совокупности составляющих абстрактную машину доступа к данным, с которой взаимодействует пользователь. Эти объекты позволяют моделировать структуру данных, а операторы — поведение данных."(с)
[Дейт К. Дж. Введение в системы баз данных. — 8-е изд. — М.: «Вильямс», 2006.]
3)Пример другого ЯМД.
В рамках иерархической модели выделяют языковые средства описания данных (ЯОД) и средства манипулирования данными (ЯМД). Каждая физическая база описывается набором операторов, обусловливающих как ее логическую структуру, так и структуру хранения БД. При этом способ доступа устанавливает способ организации взаимосвязи физических записей.
Определены следующие способы доступа:
иерархически последовательный;
иерархически индексно-последовательный;
иерархически прямой;
иерархически индексно-прямой;
индексный.
4) В каких случаях ставятся кавычки?
"В современном русском языке кавычки выполняют следующие функции:
1. Выделение безабзацной прямой речи и цитат.
2. Выделение условных (собственных) наименований.
3. Выделение слов, которые употребляются в необычном, ироническом, особом значении."(с)
[
P.S. Выражение "логическая транзакция" мною было использовано в контексте "перенести на сервер приложений" по аналогии с управляемыми (логическими) блокировками. Было заключено в кавычки и поставлен смайл :-) Но, на самом деле это очень интересная тема - как это можно сделать. Можем поговорить и на эту тему... :-)
:-) Полезная ссылка:
Автор данной темы написал в первых строках:
"...всё просто: В свойствах конфигурации меняете режим блокировки данных - "Управляемый". "(с) На самом деле: "Автоматический и управляемый". А потом... Правда он оговорился, что "На самом деле всё несколько сложнее..."(с)
Не могу представить как Олегу удалось сделать вывод, что "...остаётся только установить управляемые блокировки там где это нужно: а именно -только там где производится контроль остатков."(с) после прочтения подобного материала.
(0)
Олег.
Гениально !!!
Не надо рисовать табличку... :-)
Т.е. идея переноса в конец транзакции проверки отрицательности "базируется" на том факте, что блокировки неизбежно выставляются для всех изменяемых итогов в "момент" записи движения. А блокировки (собственно для обновления итогов) как были так и остаются на всё время жизни транзакции. И проведение документа в другой сессии будет ожидать их освобождения.
А утверждение автора про блокировки: "а может от них совсем отказаться?"(с) - имеет смысл трактовать, как: "если не требуется проверка отрицательности итогов, то и не надо выполнять код этого алгоритма".
Олег.
Бесполезно обсуждать саму суть Вашей "статьи", т.к. это не статья, а заметка в блоге. Т.е. изложено Ваше убогое представление о "прикладной логике работы ИС"(с) с очень значимыми (для читателя) ошибками того "ЗАЧЕМ они нужны"(с).
Но "пустоту" Вашей "статьи" Вы смачно снабдили хамским пассажами по адресу разработчиков 1С-а и абсолютным неуважением к читателям.
Например, про статью 2007 года, написать в 2011 году: "1С озаботились написать"(с) - мог только очень "вежливый" человек.
Основная суть моей с Вами беседы, выяснить - о какой статье идет речь. Т.к. по Вашим изложениям исходной статьи "в двух словах"(с), можно сделать вывод о существовании другой статьи. И она существует - о "Новой логике проведения" (НЛП). Но, таблица #3 абсолютно не соответствует основной цели (сути!!!) НЛП. Именно по этому моменту мы и начали нашу увлекательную беседу. Которая свелась к доказательству моей "глупости" и Вашей "умности". Что очень часто случается в разговоре пользователя некого "объекта" с разработчиком оного... :-)
Так, перефразируем:
Если допускается ситуация, когда х < 0, то блокировки не нужны.
Гм. А чем ноль так уж отличается от любого другого числа для СУБД? Если мы торгуем шариковыми ручками, и разрешаем кладовщику таскать одну из них в кармане (на всякий случай), тогда мы будем иметь не 0, а 1. Понятно, что и тогда блокировки не нужны.
Пусть у кладовщика есть помощник. Это уже две ручки. Блокировки точно так же "не нужны".
Получается, что:
1. Если допускается, что остатки могут быть меньше некоего числа, то блокировки не нужны - гласит статья.
2. Остатки (товара) в натуре наверняка меньше, чем количество атомов в наблюдаемой вселенной - не требует доказательства.
Вывод: блокировки вообще не нужны.
На самом деле, автор оговаривается: все, мол, не так просто. И верно, все не так просто. И это, получается, единственное истинное утверждение в статье...
Минус.
Итак если остатки < 0 разрешены не нужны блокировки, накладываемые в явном виде программистом, с точки зрения бизнес логики При этом платформа/SQL сервер наложат блокировки которые необходимы для обеспечения целостности данных автоматически. Собственно статья об этом... Оказывается не так просто донести такую простую мысль...
Тут вот какая штука.
Правильная формулировка смысла статьи - не нужна блокировка регистра (не считая платформенной), если ни один документ при проведении ( + ни одна обработка, если есть обработки, меняющие записи регистра в обход процедур проведения) не осуществляет чтение данных этого регистра.
НО: В такой ситуации эта блокировка даже если она и установлена, то никому не мешает. И смысл тогда ее отключать? (Ведь отключив блокировку, надо помнить об этом, чтобы все последующие изменения в программу это тоже учитывали, а это уже некоторые дополнительные затраты рабочего времени).
"если ни один документ при проведении... не использует эксклюзивного чтения остатков" А блокировка ещё как мешает... мешает другим "соседним" блокировкам. Даже не представляете насколько начинает всё быстрее работать в их отстутствие... перепроведение базы в течение рабочего дня становится возможным...
А блокировка ещё как мешает... мешает другим "соседним" блокировкам.
1. Можно ли подробнее, чем она мешает
2. Если у Вас конфигурация такова, что при проведении документов не используются данные регистров (т.е. при списании просто делаем проводки по набору измерений не зависящему от остатков) - зачем вообще базу перепроводить ???
Александр (Арчибальд) & Виталий (nafa).
Разобравшись в вопросе применения управляемых блокировок (УБ) в алгоритме проверки отрицательных остатков, можно перейти к другому вопросу - почему разработчики 1С-а, вообще, придумали инструмент УБ.
А вопрос УБ в проверке отрицательности остатков, если отрицательность никого не интересует, решается очень просто - убери весь код алгоритма проверки... ;-)
См. (107) сообщение.
1) не нужны блокировки
2) нужно перепроведение базы
Но естественно если у вас последняя типовая конфигурация под 8.2 - вам повезло. При отключении контроля блокировок не будет. Только таких пока не много...
Итог: нам управляемые блокировки сильно помогли. Желаю и остальным кто не успел опробовать этот функционал - успехов. Не все так страшно, как вначале кажется
Блокировку можно наложить как в транзакции, так и вне ее.
Блокировка сама будет снята после окончания процедуры или функции.
Принудительно можно снять блокировку в коде присвоив объекту любое другое значение.
Например:
Об = Документы.ЗаказПокупателя.НайтиПоНомеру("УТ00000034653").ПолучитьОбъект();
Об.Заблокировать(); //Накладываем бокировку
Об = Неопределено; //Снимаем блокировку
Олег (comol).
Думаю, что наличие возможности снимать блокировки не по завершению транзакции противоречит самой идей и реализации в платформе "управляемых блокировок". И вложенные транзакции тут не помогут. Т.к., насколько мне известно, реальная транзакции по отношению к СУБД остаётся одна - самого верхнего уровня. Или чего уже изменилось в новых версиях в части вложенности транзакций?
Для получения уведомлений о новых публикациях автора подключите телеграм бот: Инфостарт бот
№ 91880
Создание 26.09.11 01:09
Обновление 26.09.11 18:09
Просмотры 64898
Загрузки 0
Рейтинг
175
Комментарии 163
Код открыт Не указано
Рубрики Механизмы платформы 1С
Кому Программист
Тип файла Нет файла
Платформа Платформа 1С v8.3
Конфигурация Конфигурации 1cv8
Операционная система Не имеет значения
Страна Россия
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)