Ссылки по теме "блокировки в 1С 8.х":
0) "Для чего нужны блокировки".
Филиппов Олег (comol). 26 сентября 2011 г.
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], если схема базы данных отражает бизнес логику...
