Автоматический режим блокировки недопустим в этой транзакции. Перевод конфигурации на управляемые блокировки. VIII. Расчет количества и суммы для списания

Сегодня речь пойдет о блокировках как на уровне 1С 8.3 и 8.2, так и на уровне СУБД. Блокировка данных — обязательный элемент любой системы, количество пользователей в которой больше одного.

Ниже я распишу, как работают блокировки, и каких типов они бывают.

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

Вред системе могут принести только избыточные («лишние») блокировки, это те блокировки, которые блокируют лишнюю информацию. Такие блокировки необходимо научиться устранять, они могут привести к неоптимальной работе системы.

Блокировки в 1С делятся условно на объектные и транзакционные.

Объектные бывают, в свою очередь, оптимистическими и пессимистическими. А транзакционные можно разделить на управляемые и автоматические.

Объектные блокировки 1С

Данный вид блокировок полностью реализован на уровне платформы 1С и никак не затрагивает СУБД.

Получите 267 видеоуроков по 1С бесплатно:

Пессимистические блокировки

Эта блокировка срабатывает, когда один пользователь что-то изменил в форме справочника, а второй пытается так же изменить объект в форме.

Оптимистические блокировки

Данная блокировка сравнивает версии объекта: если два пользователя открыли форму, и один из них изменил и записал объект, то второму при записи система выдаст ошибку, что версии объектов отличаются.

Транзакционные блокировки 1С

Механизм тразакционных блокировок 1С гораздо интереснее и более функционален, чем механизм объектных блокировок. В этом механизме активно участвуют блокировки на уровне СУБД.

Неверная работа транзакционных блокировок может привести с следующим проблемам:

• проблема потерянного изменения;
• проблема грязного чтения;
• неповторяемость чтения;
• чтение фантомов.

Подробно эти проблемы были рассмотрены в статье об .

Автоматические транзакционные блокировки 1С и СУБД

В автоматическом режиме работы за блокировки целиком и полностью отвечает СУБД. Разработчик в данном случае абсолютно не участвует в процессе. Это облегчает труд программиста 1С, однако создание информационной системы для большого количества пользователей на автоматических блокировках нежелательно (особенно для СУБД PostgreSQL, Oracle BD — при модификации данных они полностью блокируют таблицу).

Для разных СУБД в автоматическом режиме используются разные степени изоляции:

• SERIALIZABLE на всю таблицу – файловый режим 1С, Oracle;
• SERIALIZABLE на записи – MS SQL, IBM DB2 при работе с не объектными сущностями;
• REPEATABLE READ на записи – MS SQL, IBM DB2 при работе с объектными сущностями.

Управляемые режим транзакционных блокировок 1С и СУБД

В всю ответственность на себя берет разработчик прикладного решения на уровне 1С. При этом СУБД устанавливает достаточно высокий уровень изоляции для транзакций — READ COMMITED (SERIALIZABLE для файловой СУБД).

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

Две блокировки НЕ совместимы, если: установлены разными пользователями, имеют несовместимые виды (исключительная/разделяемая) и установлены на один и тот же ресурс.

Физическая реализация блокировок в СУБД

Физически блокировки представляют собой таблицу, которая находится в БД под названием master. Сама таблица блокировок носит имя syslockinfo.

Таблица условно имеет четыре поля:

1. ИД блокирующей сессии SPID;
2. что именно заблокировано RES ID;
3. тип блокировки — S,U или X MODE (на самом деле в MS SQL их 22 типа, однако в связки с 1С используется только три);
4. состояние блокировки — может принимать значение GRANT (установлена) и WAIT (ожидает своей очереди).

Система «1С:Предприятие» позволяет использовать два режима работы с базой данных: режим автоматических блокировок в транзакции и режим управляемых блокировок в транзакции.

Принципиальное отличие этих режимов заключается в следующем. Режим автоматических блокировок не требует от разработчика каких-либо действий по управлению блокировками в транзакции для того. Эти правила обеспечиваются платформой системы «1С:Предприятие» за счет использования определенных уровней изоляции транзакций в той или иной СУБД. Такой режим работы является наиболее простым для разработчика, однако в некоторых случаях (например, при интенсивной одновременной работе большого количества пользователей) используемый уровень изоляции транзакций в СУБД не может обеспечить достаточной параллельности работы, что проявляется в виде большого количества конфликтов блокировок при работе пользователей.

При работе в режиме управляемых блокировок система «1С:Предприятие» использует гораздо более низкий уровень изоляции транзакций в СУБД, что позволяет значительно повысить параллельность работы пользователей прикладного решения. Однако, в отличие от режима автоматических блокировок, данный уровень изоляции транзакций уже не может сам по себе обеспечить выполнение всех правил работы с данными в транзакции. Поэтому при работе в управляемом режиме от разработчика требуется самостоятельно управлять блокировками, устанавливаемыми в транзакции.

В сводном виде отличия при работе в режиме автоматических блокировок и в режиме управляемых блокировок приведены в следующей таблице:

	Вид блокировки	Уровень изоляции транзакций
Автоматические блокировки
Файловая БД	Таблиц	Serializable
MS SQL Server	Записей
IBM DB2	Записей	Repetable Read или Serializable
PostgreSQL	Таблиц	Serializable
Oracle Database	Таблиц	Serializable
Управляемые блокировки
Файловая БД	Таблиц	Serializable
MS SQL Server	Записей	Read Commited
IBM DB2	Записей	Read Commited
PostgreSQL	Записей	Read Commited
Oracle Database	Записей	Read Commited

Установка режима блокировок в конфигурации
Конфигурация имеет свойство . Каждый прикладной объект конфигурации также имеет свойство Режим управления блокировкой данных.
Режим управления блокировкой данных для всей конфигурации в целом может быть установлен в значения Автоматический , Управляемый (установлено по умолчанию для новой конфигурации) и Автоматический и управляемый . Значения Автоматический и Управляемый означают, что соответствующий режим блокировки будет использоваться для всех объектов конфигурации, независимо от значений, установленных для каждого из объектов. Значение Автоматический и управляемый означает, что для конкретного объекта конфигурации будет использован тот режим, который указан в его свойстве Режим управления блокировкой данных : Автоматический или Управляемый .
Следует отметить, что режим управления блокировкой данных, указанный для объекта метаданных, устанавливается для тех транзакций, которые инициируются системой «1С:Предприятие» при работе с данными этого объекта (например, при модификации данных объекта).
Если же, например, операция записи объекта выполняется в транзакции, инициированной разработчиком (метод НачатьТранзакцию() ), то режим управления блокировкой данных будет определяться значением параметра Режим блокировок метода НачатьТранзакцию() , а не значением свойства объекта метаданных Режим управления блокировкой данных .
По умолчанию параметр Режим блокировок имеет значение РежимУправленияБлокировкойДанных.Автоматический , поэтому для
того, чтобы в явной транзакции использовать режим управляемых блокировок, следует указывать значение этого параметра
РежимУправленияБлокировкойДанных.Управляемый (устанавливать данный параметр имеет смысл, если для свойства конфигурации «Режим управления блокировкой данных» выбрано значение «Автоматический и Управляемый» ) .

Работа с управляемыми блокировками средствами встроенного языка
Для управления блокировками в транзакции предназначен объект встроенного языка БлокировкаДанных . Экземпляр этого объекта может быть создан с помощью конструктора и позволяет описать необходимые пространства блокировок и режимы блокировок. Для установки всех созданных блокировок используется метод Заблокировать() объекта БлокировкаДанных . Если этот метод выполняется в транзакции (явной или неявной), блокировки устанавливаются и при окончании транзакции будут сняты автоматически. Если метод Заблокировать() выполняется вне транзакции, то блокировки не будут установлены.

Условия задаются на равенство значения поля указанному значению или на вхождение значения поля в указанный диапазон.
Условия могут быть заданы двумя способами:

● с помощью явного указания имени поля и значения (метод УстановитьЗначение() объекта ЭлементБлокировкиДанных );
● с помощью указания источника данных, содержащего необходимые значения (свойство ИсточникДанных объекта ЭлементБлокировкиДанных ).

Для каждого элемента блокировки может быть задан один из двух режимов блокировки:

● разделяемый,
● исключительный.

Таблица совместимости управляемых блокировок выглядит следующим образом

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

Особенности работы в режиме «Автоматический и управляемый»

При работе в режиме управления блокировками Автоматический и управляемый следует учитывать две особенности:

● Независимо от режима, указанного для данной транзакции, система будет устанавливать соответствующие управляемые
блокировки.
● Режим управления блокировками определяется транзакцией самого «верхнего» уровня. Другими словами, если к моменту начала транзакции была начата другая транзакция, то начинаемая транзакция может быть выполнена только в том в режиме, который установлен для уже выполняющейся транзакции.

Рассмотрим перечисленные особенности более подробно.
Первая особенность заключается в том, что даже если для транзакции используется автоматический режим управления блокировками, система установит дополнительно и соответствующие управляемые блокировки при записи данных в этой транзакции. Из этого следует, что транзакции, исполняющиеся в режиме управляемых блокировок, могут конфликтовать с транзакциями,
исполняющимися в режиме автоматического управления блокировками.
Вторая особенность заключается в том, что режим управления блокировками, указываемый для объекта метаданных в конфигурации или указываемый при начале транзакции в явном виде (как параметр метода НачатьТранзакцию() ), является лишь «желаемым» режимом. Фактический режим управления блокировками, в котором будет исполняться транзакция, зависит от того, является ли данный вызов начала транзакции первым, или к этому моменту уже начата другая транзакция в данной сессии системы «1С:Предприятие».
Например, если требуется управлять блокировками при записи наборов записей регистра, при проведении документа, то управляемый режим блокировок должен быть установлен как для самого регистра, так и для документа, поскольку запись наборов записей регистра будет выполняться в транзакции, открытой при записи документа.

Ускорить 1С нажатием нескольких кнопок 2. Управляемые блокировки. September 4th, 2011

Если прочитать методику перевода конфигурации на управляемые блокировки от 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 документа не смогут списать остатки одновременно, это необходимо для логической целостности БД, но для решения прикладной задачи в данном примере вряд ли полезно.

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

Ну теперь, когда разобрались зачем блокировки нужны остаётся только установить управляемые блокировки там где это нужно: а именно - только там где производится контроль остатков. Если у вас в базе менеджер имеет право провести документ вне зависимости от того есть товар(деньги) на остатках или нет, зачем вам тогда блокировки? Можете их просто не устанавливать, или прописать и закомментировать до лучших времён. Если же у вас производится контроль остатков то как правило это 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С является оптимальным для высоконагруженных систем с большим количеством пользователей. Рассмотрим его подробнее.

Особенности управляемого режима блокировок

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

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

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

Еще одной распространенной проблемой блокировок в 1С является импорт документов. Многие разработчики используют достаточно простое решение – при загрузке не проводить документы, а только создавать. А после, с помощью простого механизма, провести все загруженные данные в многопоточном режиме по ключевым характеристикам – номенклатуре, партнерам или складам.

Алгоритм перехода на управляемые блокировки 1С выглядит просто, но неквалифицированный администратор 1С может совершить ошибки, исправить которые будет сложно. Чаще всего бывают проблемы с избыточным или недостаточным уровнем блокировок. В первом случае будут возникать проблемы с быстродействием системы, вплоть до аварийных остановок кластера серверов. Недостаточные блокировки опасны ошибками в учете при одновременной работе пользователей.

Переключение в управляемый режим

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

• В первую очередь нужно изменить режим управления блокировкой данных для конфигурации. Для этого в конфигураторе откройте дерево конфигурации и в свойствах корневого элемента в разделе «Совместимость» измените режим. Выберите пункт «Автоматический и управляемый», чтобы не возникало ошибок до того, как все объекты будут переведены на новый режим;

• Теперь настает очередь документов. Ведь именно с их помощью мы регистрируем все события, которые нужно контролировать. Начинать перевод на управляемые блокировки 1С нужно с самых загруженных документов. На вкладке «Прочее» указываем режим блокировок «Управляемый»;
• Находим все регистры, связанные с уже обработанным документом и переводим их в управляемый режим по аналогичному документам методу;
• Следующий этап включает в себя поиск и изменение всех транзакций с измененными объектами. Сюда входят и явные изменения, включающие ключевые слова «НачатьТранзакцию()», так и все обработчики документов и регистров, включающие транзакции;

НачатьТранзакцию() Для Каждого ДокументНаУдаление ИЗ СпискаДокументов Цикл ОбъектДокумента = ДокументНаУдаление.ПолучитьОбъект(); Попытка ОбъектДокумента.УстановитьПометкуУдаления(Истина); Исключение Отказ = Истина; ОтменитьТранзакцию(); Сообщить("Не удалось удалить документ " + ОбъектДокумента); Прервать; КонецПопытки; КонецЦикла; ЗафиксироватьТранзакцию();

• Исключить оператор языка запросов «ДЛЯ ИЗМЕНЕНИЯ». Заменить его можно объектом «БлокировкаДанных» с необходимостью изменить запрос и алгоритм его вызова и обработки.

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

Основные причины перехода на управляемые блокировки:

• Основная причина - рекомендация 1С:Эксперта на основании показаний или 1С:ЦУП
• Проблемы с параллельной работой пользователей ()
• Использование Oracle, PostgreSQL и .

Стоимость работ:

Суть управляемых блокировок

При работе в автоматическом режиме управления блокировкой 1С:Предприятие устанавливает высокую степень изоляции данных в транзакции на уровне СУБД. Это позволяет полностью исключить возможность получения не целостных или некорректных данных без каких-либо специальных усилий со стороны прикладных разработчиков.

Это удобный и правильный подход при небольшом количестве активных пользователей. Цена простоты разработки - некоторое количество избыточных блокировки на уровне СУБД. Эти блокировки связанны как с особенностями реализации механизмов блокировок в самой СУБД, так и с тем, что СУБД не может учитывать (и не учитывает) физический смысл и структуру объектов метаданных 1С:Предприятия.

При работе с высокой конкуренцией за ресурсы (большое количество пользователей) в какой-то момент влияние избыточности блокировок становиться заметным с точки зрения производительности при параллельном режиме.

После перевода конфигурации в управляемый режим в платформе активизуруется дополнительный функционал «менеджера блокировок» и контроль за целостностью данных осуществляется теперь не на стороне СУБД, а на стороне сервера 1С. Это увеличивает нагрузку на железо сервера 1С (нужны быстрее процессоры и больше памяти), и фактически вносит даже небольшое замедление (несколько процентов), однако куда существенней улучшает ситуацию с блокировками (меньше блокировок за счет блокировок на объект, а не на комбинацию таблиц, меньше область блокирования и в некоторых случаях меньше время жизни блокировок на чтение, т.е. не до конца транзакции). За счет этого общая параллельность улучшается.

Новые конфигурации фирмы 1С реализованы сразу в управляемом режиме.

• Вопрос: Можно ли сначала сделать аудит, а потом перевод на УБ?

Ответ: Можно , аудит послужит дополнительным обоснованием целесообразности перевода на управляемые блокировки а также оценить вклад автоматических блокировок в общее замедление и нужны ли дополнительные усилия кроме перевода.

• Вопрос: Для перевода на УБ, какой именно нужно предоставить доступ — RDP, TeamViewer ? Или можно вам выслать файл-конфигурации?

Ответ: Мы стараемся не ограничивать одной конкретной технологией удаленного доступа, годится любая технология удаленного доступа . Если для Вас не имеет значения, то практичней RDP.
Мы можем выполнить оптимизацию по высланному файлу конфигурации, но тогда не сможем отладить некоторые реальные данные и Вам придется внимательней тестировать. Если мы выполняем оптимизацию на копии базы, то мы можем тщательней протестировать, прежде чем передадим Вам результат работы.

• Вопрос: У нас 10-ть штатных программистов, которые каждый день что-то изменяют в конфе. Используется общее хранилище конфигурации». Как будет организовано взаимодействие при переводе на УБ? Или всех программистов нужно отправлять в отпуск?

Ответ: Как правило наши изменения делаются в течении пары дней. Остальное время приходится на тестирование внесенных изменений, в том числе с точки зрения требуемой логики определяемой бизнесом а не техническими соображениями. Мы можем внести изменения в отдельный файл конфигурации cf , а затем Ваш программист внесет в хранилище. В отпуск ни кого отправлять не придется . В других вариантах взаимодействия надо просто договорится какие объекты планируют захватить Ваши разработчики, чтобы мы выстроили план работ, удобный обеим сторонам. Как правило целиком конфигурацию захватить Вашим разработчикам не требуется, либо отдадите на день нам «руль».