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

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

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

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

//sale.itcity.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], если схема базы данных отражает бизнес логику…