gifts2017

Приложение к публикации: "Для чего нужны блокировки"(с).

Опубликовал Владимир (hogik) в раздел Программирование - Практика программирования

Блокировки нужны только там, где производится контроль остатков?

Ссылки по теме "блокировки в 1С 8.х":

0) "Для чего нужны блокировки".

Филиппов Олег (comol). 26 сентября 2011 г.

http://infostart.ru/public/91880/

1) "Блокировки данных в 1С:Предприятии 8".

Автор: © Белоусов Павел (Альтер Лого, Москва). Данная статья является фрагментом книги П.С.Белоусов, А.В.Островерх "1С:Предприятие: от 8.0 к 8.1". Дата выхода книги: ноябрь 2007. (Информация с ресурса http://1cexpo.ru)

http://lavelin.ru/index.php/article/1c/54-razrabotka/136-blokirovki-dannyh-v-1spredpriyatii-8

2) "Фирма 1С улучшает производительность параллельной работы в новой УТ".

Гилёв Вячеслав. 23 июля 2010 г.

http://gilev.blogspot.com/2010/07/1_23.html

3) "Управление блокировками данных в транзакции, механизм (Transaction Data Lock Control, Mechanism)".

http://v8.1c.ru/overview/Term_000000642.htm

 

Перед прочтением данной публикации необходимо прочесть [0].

 

Отправной точкой моих рассуждений служит:

"...пример "ручного" управления блокировками данных при чтении данных регистра накопления УчетНоменклатуры в обработке проведения документа РасходнаяНакладная."[3]


Соглашаясь с утверждением:

"А в управляемом у вас будет READ COMMITED, который будет накладывать и тут же снимать S блокировку при чтении, и X только при записи."[0]

Только уточню, что Х блокировка останется до завершения транзакции.


Поступаем так как рекомендовано:

"Можете их просто не устанавливать, или прописать и закомментировать до лучших времён."[0]

В нашем примере из [3] уже прописаны операторы "ручного" управления блокировками, придется их "закомментировать". Код чтения остатков для проверки "отрицательности" выполняет лишнюю работу. Думаю, его тоже следует "закомментировать".


Вроде, всё сделали как рекомендовано в [0] статье. Но алгоритм модуля проведения был разработан исходя из того, что остатки надо накапливать и, если требуется, то и проверять на "отрицательность". Т.е. кроме добавления уникальных строк движения производится еще и модификация некой, итоговой по измерению, записи в регистре накопления. И эта запись будет находится в заблокированном состоянии до конца выполнения транзакции.


Следуя предположению: "вы продаёте булочки или шариковые ручки"[0], и допустив, что отгрузка производится не вагонами (иначе трудно представит безразличие к остаткам) делаем допущение, что торговать приходится и булочками, и шариковыми ручками.

Готовим две расходные накладные на разных компьютерах с такой последовательностью товаров:

1)Булочки, Ручки.

2) Ручки, Булочки.

Запускаем проведение "разом". Платформа готовит запрос для СУБД и отравляет его на исполнение. Сессии ждут результата. Т.к. платформа ничего не знает о нашей "бизнес логике"[0] в вопросе "отрицательности" остатков, то "угрюмо" пытается наложить Х блокировку на итоговую запись регистра накопления. И получает банальный конфликт блокировок (deadlock). Возможно, что платформа расставляет "строки" документа в неком "одинаковом" порядке.

1)Ручки, Булочки.

2) Ручки, Булочки.

Это может, теоретически, упростить задачу выхода из deadlock. Но, в любом случае, полной "параллельности" проведения документов не получится. Точнее, наоборот, будет обеспечиваться, именно, последовательное проведение документов.

Чем, собственно, и призван заниматься инструмент "Управляемые блокировки"[1].

Т.е. проблемный программист получил возможность ЗАРАНЕЕ сообщить платформе, о логике своего алгоритма, прежде всего, для упорядочения (приведения к единому порядку) "воздействий" на информацию в базе данных. Чтобы платформа могла построить запрос типа "Ручки, Булочки" для ВСЕХ алгоритмов конфигурации. Например, приходные накладные и расходные накладные не будут "попадать" в deadlock, а проводиться последовательно. Это если в них будут существовать "одинаковые" объекты блокировки. А если ВСЕ объекты будут разные, то документы смогут проводится не мешая друг-другу.

Но, платформа не может упорядочить всё и вся. Например, в [2] есть такая фраза: "Следует всегда придерживаться одинакового порядка записи регистров (например, алфавитного).". Это означает, что автоматические средства платформы упорядочения "воздействий" на БД не безграничны. Приходится много прописывать и проблемному программисту руками.


Что касается задачи проверки "отрицательности" остатков, то существуют пути:

1) Если такая проверка, вообще, не требуется, то не следует использовать "итоги по измерению".

2) Если проверка "отрицательности" требуется, то поступать как описано в [2].

Есть масса других путей, но это не в текущей версии "1С:Предприятие".

Но в любом случае блокировки никуда не исчезнут.


В заключении скажу, что блокировки требуются не "только там где производится контроль остатков"[0], но и там где требуется обеспечение "согласованных данных"[0] не только на уровне СУБД, но и на уровне схемы базы данных. Т.е. на уровне "бизнес логики"[0], если схема базы данных отражает бизнес логику...

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Доржи Балбаров (Angeros) 13.10.11 05:24
Ну это все понятно. У меня вот какая проблема возникает. Кто-нибудь знает по каким причинам механизм блокировок может не работать или отключиться? При том что в тестовой базе вовремя отладки блокировки устанавливаются, и система работает корректно. Стоит запустить в боевую эксплуатацию...
2. Олег Филиппов (comol) 13.10.11 11:53
Не сдержался не поставить минус.

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


Научите меня "Изменять итоговую запись регистра" "Средствами встроенного языка". Честно, очень хочу :).
3. Владимир (hogik) 13.10.11 23:59
(2)
"Честно, очень хочу :)."(с)
Олег.
Опять, в особо извращенной форме ... ? ээээ ... читаете мои тексты. ;-)
Я не предлагаю и не собираюсь рассказывать о том как это сделать.
Это делала и делает сама платформа.
Я рассказываю, только о том - как расставлять средствами "Управляемые блокировки" последовательность обновления/чтения данных в/из БД, чтобы не возникал deadlock.
И доказываю, что Ваша статья про "Для чего нужны блокировки"(с) полное высокомерное верхоглядство. Ух, не люблю я эТТого...
4. Олег Филиппов (comol) 14.10.11 01:18
(3) hogik, Если делает сама платформа - то что же вы тогда пишите

Т.е. на уровне "бизнес логики"[0], если схема базы данных отражает бизнес логику...


Владимир, совсем запутались в показаниях.

платформа ничего не знает о нашей "бизнес логике"[0] в вопросе "отрицательности" остатков, то "угрюмо" пытается наложить Х блокировку на итоговую запись регистра накопления.


На тренинг к Рупасову сходите что-ли... он там хорошо эти моменты все объясняет

Всё, больше не комментирую. нечего здесь комментировать.
5. Владимир (hogik) 14.10.11 02:09
(4)
Олег.
Я пишу - только, то ЧТО знаю и, как мне представляется - понимаю.

Мой текст:
"Т.е. на уровне "бизнес логики"[0], если схема базы данных отражает бизнес логику..."(с)
не относится к продуктам 1С. И не может к ним относиться, т.к. их схема базы данных не отражает "бизнес логики"(с). Она отражает - "бухгалтерский" учет. :-) :-) :-)
Арчибальд; +1 Ответить 1
6. ZLENKO.PRO (ZLENKO) 07.10.13 11:51
(5) "Я пишу - только, то ЧТО знаю и, как мне представляется - понимаю"
Судя по этой статье, Вы не понимаете... Лучше уберите статью чтобы не запутывать людей.

"Если такая проверка, вообще, не требуется, то не следует использовать "итоги по измерению""
Вот это вообще непонятно. Как связано использование итогов по регистрам накопления и проверка ?
7. Владимир (hogik) 07.10.13 17:49
(6)
Владимир (ZLENKO.PRO).
"Лучше уберите статью чтобы не запутывать людей."(с)
Обязательно уберу, после того как Вы напишете свою статью на данную тему. :-)
Т.е. расскажите как "версионная СУБД" поможет избежать взаимоблокировок в схеме базы данных 1С-продукта. При наличии регистров с итогами и многострочных документов с обработкой в одной транзакции.
И возможно, в процессе написания своей статьи Вы поймете, что единственный способ избавиться от взаимоблокировок - это использовать управляемые блокировки так как описано в моей заметке. И поймете, что взаимоблокировки возникают не только в алгоритмах проверки остатков. А возникают они всегда, когда в схеме базы данных используются итоги.
"Как связано использование итогов по регистрам накопления и проверка ?"(с)
Надеюсь, Вы обратили внимание, что автор "исходной" статьи связывает "блокировки" с "бизнес" логикой контроля остатков? :-) Но, блокировки итоговых записей никак не связаны с фактом контроля остатков. Такие блокировки будут (обязаны быть!!!) всегда...
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа