Заказы на доработку 1С (сервис удаленной работы)

Хранилище

База знаний
Неназначенных незавершенных заказов: 2, свеженьких 1
Бесплатные отчеты, обработки, конфигурации, внешние компоненты для 1С Статьи, описание работы, методики по работе с 1С

Здравствуйте, гость ( Вход | Зарегистрироваться )



> Ускорить 1С нажатием нескольких кнопок 2. Управляемые блокировки.          
Vofka Подменю пользователя
сообщение 28.09.11, 18:18
Сообщение #1

У нас здесь своя атмосфера...
***********
Группа: Основатель
Сообщений: 13955
Из: Киев
Спасибо сказали: 4519 раз
Рейтинг: 3641.2

Если прочитать методику перевода конфигурации на управляемые блокировки от 1С - можно там найти много всего интересного и пугающего. На самом деле всё просто: В свойствах конфигурации меняете режим блокировки данных - "Управляемый". Всё. Могу вас поздравить - вы только что перешли на управляемые блокировки. На самом деле всё несколько сложнее - но не на много.



Что здесь не так? Контроль остатков дал сбой. 2-ой документ успел прочитать остатки раньше, чем 1-й успел их записать. При этом увидел, что на остатках 1 штука и спокойно списал их вслед за первым. Стоит оговориться, что по факту блокировки здесь всё-таки будут. 2 документа не смогут списать остатки одновременно, это необходимо для логической целостности БД, но для решения прикладной задачи в данном примере вряд ли полезно.

Теперь постараемся исправить ситуацию - в коде проведения документа пропишем установку эксклюзивной управляемой блокировки непосредственно перед чтением остатков:



При этом 1-я транзакция блокировку успеет установить, а вторая попытается установить блокировку и будет ждать освобождения ресурса, до тех пор пока не завершится 1-я транзакиця. Стоит отметить, что блокировки действуют только до завршения транзакции, и, естественно, блокировки блокируют ресурс только для изменения из других сессий. Всё логично, но паразительно как много людей об этом не знают.

Ну теперь, когда разобрались зачем блокировки нужны остаётся только установить управляемые блокировки там где это нужно: а именно - только там где производится контроль остатков. Если у вас в базе менеджер имеет право провести документ вне зависимости от того есть товар(деньги) на остатках или нет, зачем вам тогда блокировки? Можете их просто не устанавливать, или прописать и закомментировать до лучших времён. Если же у вас производится контроль остатков то как правило это 3-4 регистра, ну максимум 10-ок. Контроль можно подвесить как в общие процедуры и функции, так и в модули набора записей РН. Код предельно простой, открываем синтаксис помошник - смотрим:

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


Собственно всё сразу понятно - блокируем "товары на складх", 1 измерение становим в явном виде, значения 2-х других возьмём из источника данных - ТЧ документа.

Те кто читал книжки по 8.2 наверное помнят о "Новой логике проведения" - когда контроль остатков производится после записи движений документа. Задвались вопросом зачем это? А вот эту же табличку перерисуем так что контоль остатков и блокировка будут после записи движений:



Разница с виду не значительная - прирост производительности получаем за счет того что на время списания остатков (запись их в базу, что, собственно занимает время) блокировки ещё нет. Блокировка возникает позже к концу транзакции, куда вынесен контроль отрицательных остатков, бизнес логике приложения это вполне удовлетворяет.

Зная для чего блокировки нужны можно действительно ими управлять исходя из бизнес задач которые вы решаете. СУБД разрабатываются исходя из предположения обеспечения максисальной защиты данных. В случае если вы, к примеру, осуществляете банковские транзакции блокировки должны быть везде и на максимальном уровне. Лучше заблокировать лишние записи, чем допустить противоречивость данных.

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

Для варьирования между такими разными задачами в СУБД придумали уровни изоляции. Устанавливая уровень изоляции транзакций можно сказать СУБД какие блокировки накладывать в разных случаях (при записи и при чтении в транзакции) в разных случаях накладываются S (можно читать нельзя писать) или X (нельзя ни читать ни писать) блокировки.

Так в автоматическом режиме у вас почти всегда будет уровень изоляции SERIALIZABLE, который будет накладывать X блокировки где нужно и где не нужно, что будет существенно портить вам жизнь

А в управляемом у вас будет READ COMMITED, который будет накладывать и тут же снимать S блокировку при чтении, и X только при записи. Самый хитрый уровень. Быстро накладываемая S блокировка как раз позволяет проверить не наложена ли где на эти данные X блокировка, что и обеспечивает чтение только согласованных данных, как принято для данного уровня изоляции, а в случае если вы прочитали и выполнили действя, рекоммендованные в предыдущей статье, то не будет даже S блокировки при чтении, таким образом на уровне СУБД будет блокироваться только запись во время записи - что правильно и необходимо для сограсованности данных.

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

[необходимо зарегистрироваться для просмотра ссылки]

Спасибо сказали: alex_shkut, vadim007,

alex_shkut Подменю пользователя
сообщение 21.05.14, 10:31
Сообщение #2

Общительный
**
Группа: Пользователи
Сообщений: 37
Из: Сумы
Спасибо сказали: 5 раз
Рейтинг: 4.3

Спасибо, статья неплохая, как раз нужна такая информация. Хоть статья и старая, но все еще актуальная.
Исправьте ошибки в тексте. А далее я попрошу уточнить некоторые моменты и напишу свои наблюдения.
Цитата(Vofka @ 28.09.11, 19:18) *
сложнее - но не намного. (слитно)
Всё логично, но паразительно как много людей об этом не знают. (пОразительно)
Зная для чего блокировки нужны, можно действительно (запятая).


Цитата(Vofka @ 28.09.11, 19:18) *
"Управляемый". Всё. Могу вас поздравить

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

Цитата(Vofka @ 28.09.11, 19:18) *
Собственно всё сразу понятно - блокируем "товары на складх", 1 измерение

Тут нелишним было бы добавить, что блокировка устанавливается СТРОГО по измерениям. Т.е. если регистр подчинен регистратору, то будут заблокированы записи только по регистратору (автоматически). Если явно убрать разделитель - заблокируются все записи, но именно по набору измерений. Например, записи по Склад1 будут заблокированы, а работа со Складом2 может выполняться паралельно. Транзакция по Складу2 не пересекается с транзакцией по складу1 и будет проведена без задержки.

Цитата(Vofka @ 28.09.11, 19:18) *
Я встречал компании в которых был автоматический режим блокировки, при этом слово "замучали блокировки"

Эта ситуация нормальна для ФАЙЛОВОГО варианта БД и в файловом варианте вообще нет смысла в управляемых блокировках. БД блокируется на уровне таблиц и выигрыша от управляемых блокировок не будет никакого. Паралельная работа невозможна. Поэтому, в начале статьи я бы сразу сделал ударение, что все это имеет смысл только на клиент-серверном варианте. В случае использования СУБД PostgreSQL - это крайне необходимо. Иначе она будет вести себя как файловая.
Спасибо за внимание и за статью.

Спасибо сказали: Vofka,

Vofka Подменю пользователя
сообщение 21.05.14, 12:11
Сообщение #3

У нас здесь своя атмосфера...
***********
Группа: Основатель
Сообщений: 13955
Из: Киев
Спасибо сказали: 4519 раз
Рейтинг: 3641.2

Цитата(alex_shkut @ 21.05.14, 11:31) *
Исправьте ошибки в тексте.

Статья копировалась с первоисточника, ошибки копировались оттуда же. Так что как в песне Сектор Газа
Цитата("Сектор газа - <<Бомж>>")
... пусть остается как было

Не нашли ответа на свой вопрос?
Зарегистрируйтесь и задайте новый вопрос.


Ответить Новая тема
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 

RSS Текстовая версия Сейчас: 20.04.24, 9:08
1С Предприятие 8.3, 1С Предприятие 8.2, 1С Предприятие 8.1, 1С Предприятие 8.0, 1С Предприятие 7.7, Литература 1С, Общие вопросы по администрированию 1С, Методическая поддержка 1С - всё в одном месте: на Украинском 1С форуме!