Казалось, о работе сервера 1С и механизма блокировок за годы разработки уже знаешь всё, но 1С не перестаёт удивлять. Механизм управляемых блокировок создан 1С для того, чтобы по сути полноценно заменить механизм транзакционных блокировок на уровне сервера СУБД, отчасти из за политики "1С работает с любыми СУБД". Но на самом деле всё получилось не совсем так — далее проведём "лабораторную работу", и сделаем из неё выводы — в лучших традициях школьной физики :).
Итак начнём — простой кейс:
Конфигурация 2 объекта РС и Документ.
Регистр сведений независимый, код следующий:
Если Блокировать Тогда
Блокировка = Новый БлокировкаДанных();
Элемент = Блокировка.Добавить("РегистрСведений.РегистрСведений1");
Элемент.Режим = РежимБлокировкиДанных.Исключительный;
Блокировка.Заблокировать();
КонецЕсли;
Если ЧитатьЗапросом Тогда
Запрос = Новый запрос();
Запрос.Текст = "ВЫБРАТЬ
| РегистрСведений1.Рес КАК Рес
|ИЗ
| РегистрСведений.РегистрСведений1 КАК РегистрСведений1";
ТЗ = Запрос.Выполнить().Выгрузить();
КонецЕсли;
Если ЧитатьНабор Тогда
Набор = РегистрыСведений.РегистрСведений1.СоздатьНаборЗаписей();
Набор.Прочитать();
КонецЕсли;
Если ЗаписатьНабор Тогда
Запись = набор.Добавить();
Запись.Изм = Строка(Новый УникальныйИдентификатор());
Запись.Рес = 3;
Набор.Записать();
КонецЕсли;
Всё предельно просто.
Теперь Запускаем два сеанса.
Сеанс 1: Проводим документ с галкой "Блокировать". Ставим точку останова на строке:
"Если ЧитатьЗапросом Тогда".
Сеанс 2: Проводим документ с галкой "Читать запросом".
Внимание вопрос: "Проведётся ли документ во втором сеансе или нет?"
Нам бы очень хотелось чтобы ответ на данный вопрос был "нет".
Тем не менее, документ проводится — без особых проблем.
Повторяем эксперимент — только во втором сеансе ставим галку "чтение набора"
Тот же вопрос "Проведётся?"
Очевидный ответ — "Конечно", ведь по сути что там что там чтение всего регистра.
Тем не менее наблюдаем примерно следующую историю:
Таким образом, объектное чтение и чтение запросом работает по-разному. На мой взгляд, это в корне неправильно. При этом объектное чтение, очевидно, учитывает управляемые блокировки, а чтение запросом — ни коим образом.
Спойлер — эти тесты проводим пока в режиме "клиент-сервер".
Из эксперимента выше сделаем несколько первых выводов:
Вывод 1: 1С полностью игнорирует все управляемые блокировки при чтении в транзакции запросом.
Вывод 2: Объектное чтение и чтение запросом работает по разному
Тут можно сказать: "здравствуй фантомное чтение, неповторяющееся чтение". От "Грязного чтения" нас убережет MS SQL: в уровне изоляции READ COMMITED SNAPSHOT "грязное чтение" невозможно. Хотя я тоже сомневаюсь, потому как объектная модель 1С не полностью отражается в СУБД возможно могут быть нюансы, но примеров подобрать пока не удаётся.
Для того, чтобы понять на каком этапе своего развития в платформе 1С потеряли требование "согласованности данных" обратимся к истории.
Попробуем выполнить следующий код в разных версиях платформы:
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ
| СУММА(РегистрСведений1.Рес) КАК Рес
|ИЗ
| РегистрСведений.РегистрСведений1 КАК РегистрСведений1
|
|ДЛЯ ИЗМЕНЕНИЯ";
Выборка = запрос.Выполнить().Выбрать();
Выборка.Следующий();
Количество = Выборка.Рес;
Если Количество > 0 Тогда
Запись = РегистрыСведений.РегистрСведений1.СоздатьМенеджерЗаписи();
Запись.Изм = Строка(Новый УникальныйИдентификатор());
Запись.Рес = -1;
Запись.Записать();
КонецЕсли;
Я специально избегаю регистров накопления в примерах, потому как в РН как минимум две таблицы на уровне СУБД, а хочется продемонстрировать на одной.
Этот код выполняется в транзакции — в обработке проведения документа в моём случае. Первую транзакцию нужно конечно остановить и попытаться провести вторую. По условию мы не должны уйти в минус.
1С 8.1 и ранее (ну или просто Автоматический режим блокировки)
второй документ "висит на блокировке". После прохождения точки останова второй документ проводится, запись в РС не создаётся.
Код отрабатывает правильно как в случае остановки "после записи" так и в случае "после чтения".
Секрет конечно в инструкции "для изменения", которая кроме всего прочего превращает S блокировку в U.
На уровне СУБД уровень изоляции MS SQL — SERIALIZABLE. MS SQL блокирует всё что надо и не надо. Чтобы получить несогласованные данные надо очень постараться.
Но с параллельной работой в таком варианте конечно будут трудности, всем известно какие.
1С 8.2 и первые версии 8.3 (режим управляемых блокировок)
Появились "Управляемые блокировки". Самое главное что происходит с MS SQL при установке "управляемой блокировки" — уровень изоляции становится "READ COMMITED".
Чтобы включить его в последних редакциях 8.3 нужно выполнить:
ALTER DATABASE databasename
SET ALLOW_SNAPSHOT_ISOLATION OFF
GO
ALTER DATABASE databasename
SET READ_COMMITTED_SNAPSHOT OFF
GO
Здесь уже немного похуже. Если точку останова в коде поставить после записи — всё отработает как и в предыдущем примере — транзакция установит X блокировку и всё будет OK. А вот если точку останова поставить после чтения — получим совместимые S блокировки — одна и та же информация будет считана двумя транзакциями.
Конечно данный уровень изоляции уже не охраняет нас от ошибок "фантомного" и "неповторяемого" чтения.
В приведённом примере, тем не менее, в большинстве случаев всё будет работать верно, потому что всё-таки поведение системы в транзакции более-менее прогнозируемо — если данные считаны, то на них устанавливается как минимум S блокировка.
Конечно нужно добавить в этот код начало вроде:
Блокировка = Новый БлокировкаДанных();
Элемент = Блокировка.Добавить("РегистрСведений.РегистрСведений1");
Элемент.Режим = РежимБлокировкиДанных.Исключительный;
Блокировка.Заблокировать();
и нам уже ничего не страшно.
Зачем я тогда делаю на этом акцент?
В данном примере вы читаете остатки (по сути) — их конечно нужно блокировать.
Но если у вас в транзакции происходит чтение элемента справочника, который в данный момент может изменять другая транзакция?
Вот тут как раз S блокировка очень сильно пригодилась бы. Но об этом дальше.
Современные версии 1С 8.3
Возвращаем обратно режим версионника:
ALTER DATABASE databasename
SET ALLOW_SNAPSHOT_ISOLATION ON
GO
ALTER DATABASE databasename
SET READ_COMMITTED_SNAPSHOT ON
GO
Выполняем код — получаем "-1" как в случае установки "точки останова" при чтении, так и в случае установки "точки останова" при записи.
Теперь можно сделать ещё один вывод:
Вывод 3: чем современнее версия 1С, тем больше возможности для параллельной работы и тем меньше шансов обеспечить согласованность данных.
А теперь "Гвоздь программы": файловая база — код приведенный в блоке кода 1 выполняем в ней. Единственное изменение — код чтения данных из регистра придётся перенести в обработку, т.к. в файловой базе два одинаковых документа параллельно провести не получится.
В обработке будет код:
НачатьТранзакцию();
Запрос = Новый запрос();
Запрос.Текст = "ВЫБРАТЬ
| РегистрСведений1.Рес КАК Рес
|ИЗ
| РегистрСведений.РегистрСведений1 КАК РегистрСведений1";
ТЗ = Запрос.Выполнить().Выгрузить();
ЗафиксироватьТранзакцию();
В документе ставим галку "блокировать" и точку останова, выполняем обработку — уверенно висит на блокировке.
Убираем галку "блокировать" в документе (но не точку останова) конечно без проблем читает регистр.
Итак, в завершение "чудес" управляемых блокировок получаем их разную работу в файловой и клиент-серверной версии.
Вывод 4: Управляемые блокировки в файловой и клиент-серверной версиях работают по-разному. В файловой — "нормально".
Теперь о косяках в типовых. Для примера возьму УТ 11.
Перед записью в набор движения естественно читаются, происходит это в функции "ТекстЗапросаТаблицаТоварыНаСкладах(Запрос, ТекстыЗапроса, Регистры)" — для Товаров на складах.
Так вот, "косяк" потенциально будет во всех строчках этого запроса где "точка" фигурирует дважды:
"КОГДА ЕСТЬNULL(ТаблицаТовары.Назначение.ДвиженияПоСкладскимРегистрам, ЛОЖЬ)"
"И (НЕ ТаблицаТовары.Склад.ИспользоватьОрдернуюСхемуПриОтгрузке
И ТаблицаТовары.Номенклатура.ТипНоменклатуры В"
Что в этом плохого?
Ну вот представьте — начали вы проведение документа пока склад ещё был не ордерным, а в процессе проведения кто-то его поменял на ордерный…
Или тип номенклатуры сменил с "товара" на "услугу". Он это сможет влёгкую сделать. А вы потом не сможете доказать что "когда я нажимал кнопку всё было хорошо". Все проверки, включая конечно "обработку проверки заполнения" документ пройдёт ещё до изменения данных.
Кроме того — есть прекрасная возможность в один регистр записать данные исходя из информации что склад ордерный, а в другой — нет, и всё это в одной транзакции. Это и есть так называемое "фантомное чтение", которое, как мы помним, для "READ COMMITED SNAPSHOT" вполне возможно.
Наверное не нужно лишний раз писать что найти и устранить подобные ошибки очень и очень сложно. Ещё труднее понять что же являлось причиной подобного поведения системы.
"Эти справочники защищены от изменений, не так всё просто" — напрашивается комментарий. На самом деле всё просто. Распределенная база, полный обмен. Задано небольшое число элементов в транзакции. В каждом справочнике есть код:
Процедура ПередЗаписью(Отказ)
Если ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
Который отключает все эти проверки. В удаленной базе они могли быть пройдены, но на тот момент в ней не было актуальной копии документов, или вообще не было и не будет этих документов.
Для корректной работы проведения документа нужно чтобы на все считываемые неявным соединением таблицы накладывались разделяемые блокировки.
К слову, реально это нужно только для проведения — в других случаях необходимость что-то блокировать сомнительна.
Вывод 5: В типовых конфигурациях не учитывается необходимость блокировать записи таблиц с которыми происходит неявное соединение при проведении
Что делать я думаю понятно? Если есть параллельная работа в базе — реально параллельная, то по-хорошему при проведении документа нужно накладывать ещё кучу разделяемых блокировок, которые помогут избежать подобных ситуаций.
Почему на это не особенно обращают внимание? Да потому что эти ошибки видны только в случае реальной параллельной работы большого количества пользователей, да и то крайне редки. Если у вас много пользователей в базе 1С, у вас скорее всего наберётся несколько куч проблем более актуальных, чем описанный выше кейс. Ну а у кого всё хорошо и все вопросы решены скорее всего уже правильно расставлены блокировки, и такие крупные компании редко работают на типовых базах. Но вообще знать о таком "поведении" платформы нужно, как и учитывать его в проектах, которые ориентированы на большое количество параллельно работающих пользователей. Ведь пока мы (1С-ники) не научимся корректно работать с системами, в которых 1000+ активных пользователей и обеспечивать в них согласованность данных SAP нам на рынке не подвинуть.
P.S. Всё описанное выше "не баг а фича", вполне нормально документировано на ИТС, который всё равно никто не читает на котором вы можете детально ознакомиться с описанием работы управляемых блокировок "от Вендора" https://its.1c.ru/db/v8314doc#bookmark:dev:TI000000535
P.P.S. Если это прочитают коллеги из 1С — тут нет "камня в огород типовых" или в сторону реализации управляемых блокировок (хотя конечно хм…). Из статьи выше должно по задумке стать очевидным, что прикладным разработчикам очень не хватает возможности выбирать уровень изоляции с которым будет начинаться транзакция (в т.ч. неявная). READ COMMITED для проведения документов списания товара это слишком лайтово. Всех косяков, с этим связанных, не выловить.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Первая же ссылка в Google
Читал-читал, а все свелось к тому что «блокируйте все, что надо и не блокируйте то, чего не надо»…
В свое время управляемые блокировки мне коллега объяснил, как мьютекс. Блокировка это мьютекс. Обьектное чтение захватывает его автоматом, а запрос — нет. Вот и все объяснение.
А писать параллельный код правильно — да сложно, и без косяков никак. Тут Олег прав 🙂
(0) интересная работа!
то, что система несовершенна — стало очевидным.
а если абстрагироваться от названий «автоматический» и «управляемый», можно ли огласить (описать) алгоритм «на пальцах» — как должна вести себя блокировка записей таблиц при параллельной работе пользователей?
(желательно на примере) есть у кого красивая идея?
(0) в 8.1 (на обычных формах) всегда была возможность программировать свою функциональность по блокировкам — то есть в каждом конкретном случае разработчику приходилось прорабатывать механизм и тестировать все варианты «идеальной» параллельной работы самим, не надеясь на встроенный механизм автоматич. блокировок.
как сейчас усложнилась технология на управляемых формах — не знаю. наверное, усложнилась…
Я знал! Я предполагал! Я чувствовал! Автор молодец, грамотно изложил мои подсознательные подозрения 🙂
Нет программ,в которых » и рыбку съесть и … ( по тексту)». Обычно оценивается вероятность тех или иных событий. Вероятность изменения неордерного склада на ордерный — минимальна в процессе работы и обычно выполняется только специалистом учета или администратором системы. Если это нет — вопрос к организаторам учета на предпииятии и к специалистам внедрения.
Возьму на заметку, всё подробно и с полным анализом!
На мой взгляд, проблема блокировок заключается в том, что пока не закончилась транзакция операции, кто-то пытается изменить что-то связанное с данной операцией. Чем длительнее транзакция, тем более вероятно, что будут блокировки.
Отсюда рекомендация — сократить транзакции по времени.
К примеру, при проведении документа запускаются 10 проверок, сведения записываются поочередно в разные 10 регистров накоплений, и все это в одной транзакции. Возможно, стоит попробовать отделить какой-то регистр , и записывать в него в отдельной транзакции — в другом месте и в другое время….
В свое время я доработал отправку счетов по электронке — создал кнопку — так в период массовых рассылок — когда три бухгалтера отправляют в течение часа по 20 писем — стали возникать блокировки… Когда письмо уходит через электронную почту — транзакция по времени становится длительной — ждем ответа от электронки — ушло письмо или нет, чтобы изменить статус письма в 1С…
Тогда я создал регистр сведений «Очередь отправки писем». Блокировки исчезли, поскольку письма вставали в очередь мгновенно, а отправкой занимался робот в фоновом режиме…Делал на платформе 8.1 на БП 1.6 лет 5 назад. До сих пор работают по этой схеме.
В дальнейшем в УТ 11 перешли на расчет себестоимости при проведении реализации в отдельной транзакции — в другом месте и в другое время. Так они сократили время транзакции проведения реализации, и уменьшили вероятность возникновения блокировок.
Олег, может объясните что делает флаг ALLOW_SNAPSHOT_ISOLATION? К чему этот привет из прошлого?
1с его сто лет как не использует для переключения снепшотов. А msdn как-то не до конца понятно это объясняет. Например, здесь достаточно подробно (хотя это и не документация) . Однако, snapshot и rcsi — это два разных уровня изоляции, а речь вроде как об уровне snapshot.
Еще больше запутался с этими блокировками, теперь ваще не хочу программировать на 1С. Держать столько нюансов по работе с блокировками в голове, которые к тому же еще и меняю от платформы к платформе — это не нормально и не реально. Пока 1С определится как им нужно работать с блокировками пострадает много народу
(10) волков бояться — в лес не ходить — и на первомайские шашлыки не ездить… 🙂
Куда печальней, что нет нормальных инструментов, позволяющих с помощью менеджера 1с-ных блокировок посмотреть — какие блокировки наложены, на какие таблицы, кем и когда, с возможностью адекватного их завершения и т.д. Мониторить все это дело нечем, грубо говоря. И ТЖ тут тоже не особо помощник
(10) стоп-стоп…. никакой путаницы нету )))
Может автор немного сумбурно что-то изложил — так это только потому, что затронуты лишь отдельные специфические моменты, а не представлена вся система целиком.
В 1с нет ничего загадочного и нового, что есть в мире программирования, и все предельно просто.
Практически все лежит не в технической плоскости, а в плоскости логики и математики.
Что касается механизма управляемых блокировок, то он намного проще (на много порядков), чем блокировки СУБД (я вам не скажу за всю Одессу, а за MSSQL — скажу).
«пока создатели автомобилей не определятся куда водителям ехать — пострадает много народу»
Что это за…. ? ))) Как работать с блокировками — должна определиться не 1С, а автор программного кода, т.е. вы сами. По моему статьи про яблоки более чем достаточно. А детали поведения платформы (неявные управляемые блокировки) описаны в документации и немного в статье. Вы их должны знать. А наиболее очевидно и просто выяснить что генерирует блокировки, а что нет — посмотреть по техжурналу.
(1) еретик! Сжечь его! )))
(12)
А чем ТЖ не устроил в этом плане? Он фактически всегда дает ответы на вопросы:
— Кто поставил
— На что
— Сколько длится блокировка
— Причины конфликтов
С помощью ТЖ можно практически в реальном времени мониторить блокировки, если нужно. Такой опыт есть, даже где-то на ИС такое реализовывали. Но зачем? В нагруженных системах этот онлайн-мониторинг столько данных будет показывать, что стане бессмысленным.
Раскройте подробнее посыл, интересно узнать что еще нужно.
(1) Правильная и хорошая статья. То о чём я пишу в своей на ИТС конечно не напишут. Вернее инфу можно найти и на ИТС, мелким шрифтом в разных местах, не в базовой статье конечно
(2) свелось к тому что «блокируйте всё что надо, само не заблокируется за вас» :).
Технически там наверное всё-таки не мьютекс…. надо доп. инфу хранить и между серверами синхронизировать.
в SQL захватывается автоматом, а в 1С этого не стали делать… я думаю просто потому что очень сложно реализовать технологически.
(3) Описывал жеж
(6) всё так конечно… просто задача хорошей ИС обеспечить согласованность данных при любой ситуации…
(9) Ну насколько я помню этот флаг включает версионник для базы в MS SQL. Без него read commiten snapshot не включите.
В последних версиях MS SQL он включен по умолчанию при создании новой БД, видимо 1С это детектит.
В статье речи об уровне изоляции snapshot нет — везде конечно read commiten snapshot. Сам уровень изоляции snapshot прокомментировать не могу — не разбирался. 1С его не использует.
(14) И умирает сервер если в ТЖ блокировки включить. А их надо бы как то фоново онлайн собирать — как MS SQL делает.
(21) Смотря как настроить и что искать. 🙂 Возможно конфигурация, когда влияние сбора ТЖ будет минимальным.
Но, согласен. У SQL Server инструменты гораздо лучше в этом плане.
(22)
Запись всех блокировок в текстовый файл… ну это убийство дисковой подсистемы при любом раскладе. ИМХО конечно, но у меня настроить так чтобы работало быстро не получается….
(20)
Да, все верно. Snapshot будет тяжеловат для 1С. Не встречал, чтобы его использовали где-то… Поспрашиваю на sql.ru
В последних версиях MS SQL он включен по умолчанию при создании новой БД, видимо 1С это детектит.
А вот тут — НЕТ.
Прикрепил файлик… Нигде, кроме master и msdb данный режим не используется. Это собственно два разных, режима. И на сколько я понимаю по различным описаниям на msdn — никак не пересекающихся. Один флаг отвечает за включение версионирования уровня RCSI, второй Snapshot. Думал, что вы, как человек бывалый, мне про это подробнее ответите )) Очевидно, что платформа первым флагом не оперирует. А рекомендация устанавливать два флага появилась с каких-то бородатых годов и сейчас вероятно не актуальна. SI появился кажется в 2005. И возможно там нужно было оба флага устанавливать.
(24)
Ну вообще 2017 год MSDN:
The following statements activate snapshot isolation and replace the default READ COMMITTED behavior with SNAPSHOT:
SQL
Копировать
ALT ER DATABASE MyDatabase
SET ALLOW_SNAPSHOT_ISOLATION ON
ALT ER DATABASE MyDatabase
SET READ_COMMITTED_SNAPSHOT ON
Я не разработчик Micrisoft и даже не MVP по MS SQL, поэтому обычно следую документации если это работает.
А ещё я буду долго ржать если второй флаг без первого не работает и 1С по факту не использует версионность :)))))))))))))))
(23) вы о упрблокировках 1с? Неожиданно… Если исключить <property name=»Locks»> и хоть какого-то порог длительности установить, то все весьма компактненько…
(26) а если установить порог и длительность смысл их вообще собирать? :)))))
(27) обычно сбор ведь идет уже тогда, когда знаешь что ищешь.
Вообще, сбор массовый логов лучше изолировать от прода по максимуму. В этом случае отдельный диск или SSD. Анализ и разбор логов тоже на отдельном сервере.
Да что мы спорим 🙂
ТЖ это монстр, который надо готовить по необходимости)))
На проде обычно включен только сбор ошибок. Конфликты управляемых блокировок обычно решаются без ТЖ, только при сложных загадочных случаях приходится включать.
Если нужен прямо онлайн мониторинг, то пробовать отдельные диски и сервер для анализа данных с Эластиком!
(14) есть инструменты как консоль запросов, консоль заданий — открыл и мониторишь — вот такой инструмент нужен.
В сравнении с ТЖ — ТЖ перегруженный неудобный сложный. Консоль заданий — открыл и мониторишь…
Есть задачи и в не нагруженных системах — при которых было бы полезно мониторить блокировки. Да и потом в мониторе блокировок должен быть фильтр по объектам , которые мониторим…
(25) В документации же нет указания «нажимать все кнопки одновременно» )) Скорее трудности перевода.
Это два разных уровня изоляции. С разным поведением для чтения и модификации, с разными сценариями использования, с разной нагрузкой на tempdb. Достаточно погуглить Read committed Snapshot Isolation VS Snapshot Isolation
В общем случае MS не рекомендует использовать SNAPSHOT ISOLATION, а ограничиваться RSCI.
А то что флаг READ_COMMITTED_SNAPSHOT точно работает без ALLOW_SNAPSHOT_ISOLATION проверял лично еще на совместимости 8.2.16 — при равномерной нагрузке продуктовой базы поведение в части блокировок СУБД ну очень явно отличалось.
(28)
Сбор обычно идёт когда уже что то случилось и надо понять что…
Онлайн с ТЖ не получится… в Elastic тоже надо сначала выгрузить…
(0)
Если Блокировать Тогда
Блокировка = Новый БлокировкаДанных();
Элемент = Блокировка.Добавить(«РегистрСведений.РегистрСведений1»);
Элемент.Режим = РежимБлокировкиДанных.Исключительный;
Блокировка.Заблокировать();
КонецЕсли;
Если ЧитатьЗапросом Тогда
Запрос = Новый запрос();
Запрос.Текст = «ВЫБРАТЬ
| РегистрСведений1.Рес КАК Рес
|ИЗ
| РегистрСведений.РегистрСведений1 КАК РегистрСведений1″;
ТЗ = Запрос.Выполнить().Выгрузить();
КонецЕсли;
Показать
Если после установки исключительной блокировки, таки прочитать что-нибудь из этого регистра сведений в той же транзакции. Блокировка на чтение сработает?
(14) в том то и дело, что собирать с помощью ТЖ все блокировки 1с-ные — тяжко как для сервера, так и потом для анализа.
А хотелось бы вот что: ставишь в консоли администрирования «Пороговое время = N минут», показать все блокировки, которые висят дольше порога. Фильтр на таблицы метаданных тоже бы неплохо. Нет, может я чего-то не знаю и такое уже кто-то сделал? Просто у менеджера блокировок ведь есть эта информация! Он же как-то дает это понять другим сеансам, другим rphost ну и т.д.! Взаимодействие между процессами и т.д. и т.п. Просто дайте нам тоже посмотреть, вот и все. Хотя бы посмотреть
И кстати, автор. По поводу блока кода №1. Замените набор регистра сведений набором регистра накопления — и Вы удивитесь)))
Спойлер:
Объектное чтение набора РС в транзакции накладывает неявную разделяемую управляемую блокировку.
Объектное чтение набора РН в транзакции НЕ накладывает неявную разделяемую управляемую блокировку.
Такое ощущение, что наборы записей РС и РН разные люди программировали в 1С.
Вывод 1: 1С полностью игнорирует все управляемые блокировки при чтении в транзакции запросом.
Ну и как бы логично, что игнорирует. Внутри транзакции запросом можно прочитать только «чистые» (закоммиченные) данные и их чистоту Вам СУБД гарантирует, а не сервер приложения. На самом деле, хотите обеспечить дополнительную «чистоту» и неизменность тех данных, которые читаете — ставьте перед чтением сами блокировку и именно на ней и отвалится выполнение кода по таймауту (если уже есть блокировка).
Именно, кстати, на чтении РС у Вас и отваливается выполнение по таймауту, так как см. выше — неявная разделяемая управляемая блокировка.
Отсюда, собственно и пошли все эти «старая методика — новая методика», вся суть которых заключается в «когда блокировать» — поближе к концу транзакции или подальше…
И с вот этим Вывод 5: В типовых конфигурациях не учитывается необходимость блокировать записи таблиц с которыми происходит неявное соединение при проведении
не могу согласиться.
Зачем блокировать то, что я в результате выполнения алгоритма менять не собираюсь? Как раз таки это избыточно будет. Собираюсь менять остатки — вот их и блокирую. Ну а то, что товар на момент чтения был товаром, а потом стал услугой — ну извините, сами себе злые буратины. Это уже уровень защиты в прикладной логике должен отвечать, при записи вида/свойства номенклатуры. А то так можно эту цепочку продлить еще и еще, у вида/свойства номенклатуры тоже свои реквизиты есть, у тех тоже свои и т.д. и т.п. Что же нам — все разименования блокировать? Не надо так )))
(34)
В этом весь смысл данной статьи :)))) Дело в том что в типовых 1С их не ставит… при проведении документа «с контролем» очевидно должна быть «дополнительная чистота»
(29) (33) Поддерживаю.
Вот был бы аналог Extended Events, то жизнь стала бы проще.
Сейчас удавалось передавать асинхронно данные ТЖ в ElasticSearch с помощью утилиты на .NET Core (C#). Но событий было ограниченное количество, т.к. фильтры были установлены. Сам ТЖ за сутки набирал всего 2 ГБ. Что будет, если собирать все блокировки не могу сказать. Возможно, что передача данных в ES займет значительный объем ресурсов.
(16)
К слову, про файловые и клиент серверные версии, есть такая табличка с сайта 1С, которая абсолютно все объясняет
(16)
И ещё вопрос — зачем для чтения (ЧитатьЗапросом) используете исключительную блокировку, а не разделяемую
(37)
Как бы мне хотелось чтобы это было так.
Конечно она не объясняет почему управляемые блокировки — пусть даже не всю таблицу в файловой и клиент серверной версии работают по-разному
(38) Ну для контроля остатков должна быть исключительная… А то ведь кто-то ещё прочитает
(37) эта табличка показывает как правильно называется составляющие технического решения Сама проблема в применении к 1с в том, что специалист по sap (например) при переходе с 1с на что то другое имеет и квалификацию и полномочия и возможность прямого доступа к данным при помощи СУБД не используя ни код ни платформу ни лицензии 1с.
Достаточно описания структуры метаданных.
А 1с ник при такой работе с данными чего то нарушает, а без соответствующего сертификата ещё и не имеет необходимой квалификации.
«либо крестик снимите либо трусы наденьте.»
(30)
Ну верю… Не только у 1С есть косяки в документации
ХЗ что это такое. Его никто не использует
у меня всё норм с английским. По-другому перевести фразу «выполните эти инструкции SQL чтобы включить Read commited snapshot вместо Read commited» трудно.
(32)
хоть заблокируйтесь и зачитайтесь :). Блокировка нужна для защиты от других транзакций.
(34)
именно так а никак иначе. Представьте что у вас меняется не «товар на услугу» а «вагон нефти» на «вагон хлора» в распределенной системе 🙂
Более того — проблема не в том что номенклатура из товара стала услугой… а в том что по регистру «товары на складах» она пройдёт как товар, а по регистру «себестоимость» уже как услуга. В рамках одной транзакции записываются оба регистра. Это ошибка согласованности данных.
А вцелом коммент очень дельный
(40)
Это только мое предположение, но мне кажется, что дело здесь в объекте НаборЗаписей. Платформа его интерпретирует как объект, производящий запись данных (даже только при чтении набора) и работает с ним не так, как с объектом Запрос. Я бы обратился с этим вопросом в поддержку фирмы 1С ради интереса
(40) Сейчас в тренде новый подход к проведению. Сначала проводим документ as is. А потом снимаем остатки на регистрах. Вышли в минус — откатываем транзакцию.
(46) «Сейчас» это лет 5 или 6 вроде? :)). Но суть дела не меняет — всё равно надо накладывать исключительную блокировку.
(45) Всё так. И это будет официальная позиция 1С. Но суть в том что чтобы правильно наложить все блокировки при чтении запросом нужно или выполнить его дважды или полноценно разбирать, а это уже сделать из 1С сервер СУБД по сути 🙂
(48) Ни менеджер среднего звена ни бухгалтер с екселем и выгрузкой из СУБД тоже в этом комбайне не нуждаются. А для операторов достаточно любой (той же веб надстройки над любой СУБД) для формирования и распечатки первички.
И тогда все те же блокировки возникают на уровне коммуникации между людьми и решаются так же.
Если есть проблемы с коммуникациями, то полноценно заменить их при помощи 1с не получится.
И если за 20 лет существования 1с проблема параллельной работы с контролем остатков не решена до сих пор, значит на нее нет спроса в данном сегменте.
А те сегменты где такая потребность есть уже давно заняты.
(49)
И будут заняты другими пока проблема не будет решена 🙂
(49) проблема решается тем, что остатки контролируются после записи движений. И тот документ, при проведении которого зарегистрирован минус, просто отменяет транзакцию. Это сложно понять современным 1С-никам, но, с другой стороны, и не надо — без них разберутся.
(51) зарегистрирован минус на когда?
При одновременном проведении двух документов с одинаковым временем запрос это вообще может определить?
(52) ну у обоих пользователей документ не проведется, что такого? Фактически две транзакции. В первой остаток меняется, во второй меняется, вот первая транзакция записывает регистр, в это время в модуле регистра срабатывает событие «при записи», там читается остаток по отбору из записанного уже набора записей и проверяется, есть ли минус. Если есть — отказ. То же самое во втором документе. Если у обоих внезапно стал минус — ну оба отвалятся и потом кто-то снова проведет документ.
Сам SQL (если говорить о СУБД) не пишет данные одновременно — он одновременно в очередь поместить может. А пишет отдельный поток.
ЗЫ: Вообще в компьютере нет ничего «одновременного» в плане записи на один диск. И для целостности софт делает sync, чтобы быть уверенным в изменениях. А вот при чтении мы можем что-то взять из кеша дважды, но, опять же, кеш обнолвляется при записи, которая не одновременна. Такой вот «парадокс».
(53)Вы меня простите, не хочу никого обидеть. Но вот есть два спринтера. Они пересекают финиш и срывают ленточку одновременно. Приз достанется кому то одному, что тут такого.
Но журнал регистрации отключен в конфигураторе, а запросы к журналу транзакций превратили бы 1с в СУБД, а если учитывать файловую систему с кэшами и буферами то и в ось..
И вот уже программист 1с заводит регистр сведений и прописывает очередь проведения с учётом приоритета пользователей по своему усмотрению.
Сначала проводить все документы Тани, затем Васи и и только потом МарьИвановны. И все они на процентах.
(51) С таким подходом производительность вашего приложения упадет в разы на больших нагрузках
(47)Не только исключительную но и уменьшать количество записей в одной транзакции, лучше сделать несколько последовательных транзакции ,1 строка 1 транзакция , чем 1 транзакцию для записи 100 строк.
(56) даже в этом случае документ или справочник с табличными частями при изменении или добавлении строки будет записан целиком. Или нет?
(57) На ваши транзакции наложится еще главная транзакция на весь документ или справочник. Поэтому все эти танцы с бубнами просто пустая затея. Не забывайте есть транзакция 1С и транзакция сервера базы данных, это разные вещи, если вы делаете блокировку в коде 1С это во все не означает что эта блокировка происходит на sql сервере, блокировки на скл сервере включаются только тогда когда действительно происходит запись/чтение данных самой 1С. Чем быстрее будет выполнен код 1С в транзакции тем меньше будет блокировок.
Если хотите добиться максимальной параллельности выполнения транзакций:
1. максимально исключите использование табличных частей у документов и справочников.
2. Используйте минимум транзакций в своем коде, включайте транзакции только тогда когда это действительно необходимо.
3. Не выполняете в транзакции какие либо емкие операции
4. проверяйте остатки и другие параметры не во время записи данных, а во время подготовки данных перед записью, до начала основной транзакции записи данных. Например во время редактирования данных в табличной части документа.
(54) ну вот пересекают они финишь, но один оказался в очереди раньше — никуда не деться. И второй при записи регистра упирается в Х-блокировку ресурса уже на сервере SQL и будет ждать. Если регистры во всех документах записываются в одной последовательности, то дедлока не будет — будет простая очередь ожидания. Именно для этого в свое время придумали механизм записи регистров при записи документа — там последовательность строго блюдется. А еще в УПП лет сто назад (в 8.1) контроль регистра остатков был сделан в модуле набора записей этого регистра. И ничего не тормозило у товарищей с нормальной техникой, и никогда (ни разу) не было никаких случайных отрицательных остатков. Читайте «библию разработчика 1С» — там это уже лет надцать как описано. А то, что себе придумывают люди — это от незнания.
(56)
лучше конечно… но согласованность данных при такой истории обеспечить намного сложнее.
(58) не понимаю, вы хотите сказать что блокировка сервера 1с накладывается на объект метаданных 1с (например документ или справочник с табличными частями, но без подчинённых справочников или записей регистра сведений)
(61)Ну да, за исключением документов, все движения тоже по падают в транзакцию и блокируются (в зависимости от режима записи/чтения)
(60)Это вопрос планирования архитектуры приложения и методик разработки. Много конечно из 1С не выжать но что то можно.
удалил
Спасибо. Пробелы постепенно заполняются.
(43) Я о другом. В примерах, везде где ставится явная блокировка, впоследствии идет чтение данных и блокировка ставится на основании того, какие измерения были считаны. После этого в других транзакциях уже нельзя писать/читать те же измерения, что были заблокированы в первой транзакции. В статье идет установка блокировки, но, видимо, данные не читаются, так как для этого должны стоять две галочки одновременно и «Блокировать» и «ЧитатьЗапросом». Какая именно комбинация галочек установлена из статьи непонятно.
(66) ничего не понял про галочки. В примере данные лочатся а потом читаются. Блокируется весь регистр потому что лень было делать более полноценный пример
(67) Я сделал тестовую обработку, чтобы воспроизвести эффект, когда блокировка на чтение не ставится при явном задании исключительного варианта. Пробовал на 3 версиях платформы: 8.2, 8.3.7, 8.3.13. На трех конфигурациях ERP, ЗУП 2.5, БП2.0. Поведение везде одинаковое — регистр блокируется от чтения. Возможно дело именно в том, что если перед чтением данных не ставить никаких блокировок, то платформа даст это сделать, так как не будет выполняться попытка сравнения совместимости установленных блокировок (Исключительная+Никакая = Дает читать, Исключительная+Исключительная = Не дает читать) ?
(68) база не файловая?
(69) Все 3 базы клиент-серверные, на продакшене.
В общем я проверил. Заблокировал «Справочник.Пользователи», если открывать его в другой сессии или использовать консоль запросов, то данные из него прекрасно читаются. Но если запустить эту же обработку и попробовать установить Блокировку, то через 20 секунд выдает ошибку
«Конфликт блокировок при выполнении транзакции:
Превышено максимальное время ожидания предоставления блокировки»
Т.е. через управляемую блокировку можно обезопасить от чтения — идентичные объекты в разных сессиях с одним и тем же кодом, где идет попытка установки несовместимой блокировки. От запросов без использования объекта БлокировкаДанных — это не спасает.
(70) Но вот что интересно. От ЗАПИСИ блокировка спасает. Установив исключительную блокировку в обработке на «Справочник.Пользователи» и попытавшись снять галочку «Показывать в списке» с последующей записью — я получаю все тот же конфликт блокировок.
Таким образом получается, что исключительная управляемая блокировка защищает от чтения только, если перед чтением идет попытка установки блокировки. Если нет, тогда она срабатывает уже при записи (видимо уже на уровне СУБД).
Вы хотите сказать, что если на всю таблицу справочника пользователи наложить исключительную блокировку, то при обновлении ранее открытого списка мы получим пустой список или неполный?
А как же политика оптимистических блокировок?
(71) Правда, если блокировка будет снята после удачного чтения, но до попытки записи или в течении тех 20 секунд ожидания блокировки, то могут записаться некорректные данные. Таким образом в критичных местах надо обязательно использовать объект БлокировкаДанных явным образом, чтобы уберечь свой код от возможного чтения заблокированных данных.
(72) Оптимистические и пессимистические блокировки относятся к объектным блокировкам, в основном касаются интерактивного варианта работы. Управляемые (транзакционные) блокировки не будут накладывать эти варианты блокировок на записи при использовании (это два разных механизма, которые друг о друге ничего не знают). Как я понимаю, с версии 8.3 в режиме Управляемых блокировок СУБД MSSQL использует уровень изоляции RCSI (Read Commited Snapshot Isolation), что позволяет повысить параллельность работы (concurency) за счет того, что в момент блокировки записи на чтение — копия (версия) данных (текущей транзакции) помещается в TempDb, а остальные транзакции читают основную версию. В моем случае, установка блокировки справочника Пользователи на чтение приводит к тому, что все остальные транзакции по факту читают старую (существующую) версию справочника, до завершения моей транзакции. Если другие транзакции попробуют явно установить блокировку через БлокировкаДанных или неявно, когда сама СУБД начнет её устанавливать, через попытку записи справочника — тогда блокировка встанет в очередь.Если мы хотим избежать рассогласованности данных в собственной транзакции и считаем, что изменение данных другими транзакциями критично для нашей бизнес-логики, то необходимо установить блокировку в явном виде, чтобы механизм Управляемых блокировок 1С и СУБД среагировал. В противном случае считается, что считанная («старая» версия) данных имеет право на существование, так как заранее неизвестно завершится транзакция удачей или нет. И все кто не наложил блокировку в явном виде — сам отвечает за последствия. Это не является ошибкой, так как решение принимается исходя из логики прикладного решения, и в основном играет положительную роль, увеличивая параллельность работы системы. Проблема может возникнуть, если мы ничего не блокируем, считываем «старую» версию и на основании этой информации пишем в совершенно другое место (в этом случаем блокировок надо накладывать, как минимум, две)
Поправьте меня если я не прав.
(68) Посмотрел. Ну ещё один пример аналогичный приведённому. Не ставим блокировки = не защищаемся. Собственно у вас они только в начале.
(70)
можно конечно. Другой вопрос что это надо делать своими руками
(74) Во всём прав (вроде как) кроме того что к форме списка справочника это никак не относится ибо там нетранзакционное чтение данных, которому абсолютно покласть на все блокировки и уровни изоляции 🙂
Авто!!! Напугал!
Ты должен исключение получить, когда будешь блокировать второй раз регистр. Т.е. проводи эксперимент при всегда включенной галке блокировать. Вот если ты смог заблокировать данные, то и читай их, зная что никто их не поправит в этот момент, т.к. ты наложил блокировку.
Удивлен, что автор для многих открыл америку. Значит, статья в самом деле полезная.
ИМХО, если понимать, как работают блокировки СУБД и знать что управляемые блокировки не имеют никакого отношения к уровню СУБД, то вывод что управляемые блокировки никак не влияют на чтение запросами — очевиден.
Аналогичные реализации управляемых блокировок я еще на 7.7 припоминаю (с помощью внешних библиотек).
(79)
а можете пояснить почему для вас этот вывод очевиден?
Просто опыт говорит что в 1С работают одни разгильдяи и вот уж этого они точно не сделают? 🙂
(78) Галка «блокировать» это неявная установка управляемой блокировки просто.
(81) Вы, наверно, меня не поняли. У вас же документ проводится. Если установлена галочка блокировать, то вы накладываете ЯВНУЮ управляемую блокировку на регистр. Так вот чтобы не получать неконсистентных данных — это надо делать ВСЕГДА (блокировать). Если вы блокировку не наложили перед чтением — то оно будет ГРЯЗНОЕ. Что здесь удивительного? 🙂
(80) Потому, что по тексту запроса невозможно в общем случае определить, пересечется ли получение результата запроса с управляемой блокировкой.
Ну вот смотрите. Наложил я блокировку по конкретному ТМЦ. А выбираю данные по всем ТМЦ из регистра за период. Анализом текста запроса невозможно определить — попадется ли там заблокированный ТМЦ. Анализом результата запроса это определить также невозможно — блокируемые данные могут использоваться как промежуточные и не входить в конечный результат. Приходим к тому, что контролировать это возможно только на уровне СУБД.
Но управляемые блокировки — это грубо говоря просто системный справочник. Полностью отдельно стоящая параллельная система. И ничего другого тут особо не придумаешь. Я бы реализовывал точно также. И как я уже говорил, подобные реализации были и для 7.7. Если не путаю, автор ToySQL что-то подобное продавал.
(36) Отдельная статья с рассказом «как готовить ТЖ и ЕЛКу» будет?
(85) а нужно?
В том плане, что об этом вроде и так много сказано. Даже на ИС был материал.
(86) Пропустил видимо 🙁 Пошел искать…
(87) не найдете — пишите. Что-нибудь придумаем 🙂
(83)
тем не менее СУБД это как то делает. Если очень хочется можно сначала прочитать а потом заблокировать. А можно тупо уровень изоляции поднять.
. Печально. Не смог донести видимо :(. Я бы такую херь делать не стал. И тому кто сделал по рукам бы надовал. Я бы дал возможность разработчику поднимать уровень изоляции. Или принудительно бы поднимал при проведении.
(89) СУБД это делает с помощью блокировок СУБД. Уровень изоляции — это те же самые блокировки (плюс переключатель блокировочник/версионник в mssql).
С блокировками на уровне СУБД и поднятием уровня изоляций в 1С уже наигрались в автоматическом режиме блокировок. При проведении как раз и поднималось до Serializable. Но оказалось, что это не самый лучший вариант — слишком из пушки по воробьям. Целостность-то обеспечивается, но параллельность далеко не такая, как хотелось бы. Хотелось бы более тонкое управление блокировками, но его можно обеспечить только на прикладном уровне. Разбор полетов как раз и привел к появлению управляемых блокировок, которые можно применять «хирургически», а не «по площадям». Печально, что вы этого не понимаете. Здесь в принципе нет «более лучшей альтернативы».
ЗЫ. Хотя 🙂 Если бы у 1С была своя СУБД, тогда 1С теоретически могла бы прямо транслировать управляемые блокировки в блокировки этой СУБД. Вот тогда бы могло получиться как вы хотите. Со сторонними СУБД на текущий момент это невозможно.
(91) я понимаю в общих чертах что конфигурация на файловой СУБД и на sql с управляемыми блокировками долга быть не только написана с дополнительными командами заблокировать освободить, и даже не только с запросами (используя временные таблицы или нет) но и иметь другую архитектуру.
И несмотря на возможность открыть ее в конфигураторе, разработать конфигурацию для такого режима работы в файловой базе не получится и протестировать тоже.
(91)
«Садись два». Тут конечно нужно прочитать несколько матчасти. Уровень изоляции это намного более широкое понятие, и в общем случае не имеющее отношения к блокировочник/версионник.
Ещё раз постараюсь объяснить — надеюсь получится:
1) В СУБД реализованы НОРМАЛЬНЫЕ — ХОРОШИЕ блокировки. Которые вцелом всех устраивают.
2) Потому как в разных случаях разные требования к согласованности данных в СУБД придумали уровни изоляции. От Read Uncommited — когда нам «всё равно», до «Serializable» когда «не дай бог что сломается»
3) Блокировки в СУБД это целая нехилая система, с совместимостью, эскалацией, предварительным расчетом и т.п. которая ОЧЕНЬ сложна, но при этом отработана годами
4) УБ в 1С — это просто некие «флажки» — «тут можно, а тут нельзя», предельно упрощенная и не имеющая ничего общего с «тем как надо», более того — никак не распространяющаяся на реальные данные.
Так вот — 99% НОРМАЛЬНЫХ систем используют в своей работе механизм блокировок и транзакций от СУБД, потому как реализация аналогичного «очень трудна и дорога». И да, в них параллельность обеспечивается на лучшем уровне (Dynamix Ax и SAP (который не HANA)).
В 1С же не дали возможность нам использовать механизм транзакционных блокировок из СУБД, вместо этого напилили свой костыль, при помощи которого в теории можно обеспечить согласованность данных, но для этого надо просто умереть.
а про
вы начитались методичек от 1С и просто не понимаете что это возможно БЕЗ 1С и БЕЗ управляемых блокировок.
(92) да в общем-то нет. На то и универсальный объект Управляемые блокировки. Его стратегия определяет общие правила для разных СУБД. В том числе и для встроенного. Конечно есть особенности использования под разные СУБД, но они исключение из правила.
Это как запрос и СКД. В СКД тоже используется запрос, но он скорее руководство к действию, а не пошаговое выполнение.
Так и с управляемыми блокировками. Это объект (класс), который сам определяет, что и как заблокировать в самом sql.
(92) (94) В общем то да. Я бы сказал «хорошая» конфигурация на 1С должна разрабатываться или под использование в файловой версии или под использование с конкретной СУБД.
Типовые конфигурации я не отношу к «хорошим» — я их отношу к «типовым».
(93) а теперь отбросьте знания про последние версии mssql и оперируйте полным спектром поддерживаемых версий sql в 1С (в том числе и встроенной). А теперь создаете правило, которое поддерживается ими всеми и сразу.
(96) что мешает 1с сузить поддерживаемые версии СУБД для каждого релиза конфигурации, как платформы к примеру.
Лицензионная политика ms sql?
(97) предлагаете для каждой версии СУБД отдельную конфигурацию?
(98) при запуске конфигурации пишут же обновите платформу. А почему не СУБД? Его надо заново покупать или только переустановить?
(17) «Мьютекс» — это абстрактно, чтобы было проще объяснить принцип: захватил/отпустил. А что там внутри — это один БГ ведает.
(25)
Использует. На ИС, по-моему, Андрей Бурмистров, показывал графики с разницей замеров между режимами.