Золотые костыли

Немного о программировании.

Золотые костыли

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

5. Пример отладки.

После обновления конфигурации при первом запуске вышла ошибка, с комментарием ОбщийМодуль.ДлительныеОперации.Модуль(376): Недопустимое значение параметра. По этому адресу находится код

ТекстОшибки = КраткоеПредставлениеОшибки(Задание.ИнформацияОбОшибке);
ВызватьИсключение(ТекстОшибки);

В отладчике настроил остановку, удалось получить более подробную информацию из переменной Задание.ИнформацияОбОшибке. Оказывается, ошибка происходила в модуле ОбновлениеИнформационнойБазы, код

ПланыОбмена.ЗарегистрироватьИзменения(Узел, Данные);

Тут не подходит безусловная остановка или остановка с условием. Останавливаться по каждой ошибке – тоже не подходит: слишком много ошибок завершения фоновых заданий. В отладчике настроил остановку по ошибке 

Нашел данные, на которых происходит ошибка регистрации и исключил их из обработки.

4. Потерянное регламентное задание.

После обновления конфигурации в журнале регистрации появились записи "{ОбщийМодуль.ОбщегоНазначения.Модуль(2385)}: Регламентное задание недоступно по функциональным опциям или не поддерживает работу в текущем режиме работы программы. Выполнение прервано.". Еще в сообщении есть название регламентного задания, но в диспетчере регламентных заданий такого задания нет. В режиме конфигуратора не удается найти, откуда задание запускается.

По названию задания нашел связанную с ним функциональную опцию. Остановил регламентные задания в консоли кластера. Включил опцию. Задание появилось в диспетчере задач. Отключил выполнение регламентного задания. Все просто. Для осознания этой простоты мне потребовалось всего пару дней. )))

Список функциональных опций для регламентных заданий находится модуль РегламентныеЗаданияПереопределяемый, процедура ПриОпределенииНастроекРегламентныхЗаданий(Настройки)

3. Нестандартное использование замера производительности.

Бывает, что код плохо структурирован, в нем трудно разобраться. )) Например, нам нужно быстро найти, какой макет используется в печатной форме. Запускаем замер производительности, выполняем печать, завершаем замер. Получаем листинг выполненных команд. Выполняем поиск (Ctrl+F) слов "Макет", выбираем нужную строку.

2. Попытка, еще попытка…

Используйте конструкцию Попытка … Исключение … КонецПопытки правильно. ))

Между Исключение … КонецПопытки обязательно должна находиться команда ЗаписьЖурналаРегистрации(); и возможно Сообщить(); ВызватьИсключение; Программа не должна прятать происходящие ошибки, их обязательно выводить в журнал. Кто-то должен ежедневно анализировать и устранять причины ошибок. Казалось бы, это банально, но многие ли из нас начинают день просмотром журнала регистрации ? Кстати, даже некоторые «коробочные» решения не всегда используют ЗаписьЖурналаРегистрации(). Поэтому приходится мучительно долго искать причину очередного "отказа программы".

Далее, не нужно создавать такую ситуацию, когда конструкция выполняется в транзакции, а внутри ее прячется еще одна транзакция, например

Процедура ПриЗаписи(Отказ)

Попытка

ДокументПродажи = Документы.РеализацияТоваровУслуг.СоздатьДокумент();
...
ДокументПродажи.Записать();

Исключение
....
КонецПопытки.

...
КонецПроцедуры;

В этом случае конструкция "Попытка … Исключение … КонецПопытки" бесполезна и вредна. В случае, если во вложенной транзакции произойдет ошибка, внешняя транзакция тоже откатится, но причины никто не увидит. Это фатум.

 

1. Удачный пример блокировки

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

Вариант 1. Сделать блокировку чего-либо на время печати документов кодом типа

Блокировка = Новый БлокировкаДанных;
ЭлементБлокировки = Блокировка.Добавить();
ЭлементБлокировки.Область = …
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
ЭлементБлокировки.УстановитьЗначение…
Блокировка.Заблокировать();

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

Вариант 2. Записывать в регистр сведений информацию о том, что регламентное задание должно ожидать некоторое время – тоже отпадает. Как обеспечить корректную работу такого регистра в случае ошибок, сбоев и аварийного завершения программы ?

Вариант 3. На помощь пришли объектные пессимистические блокировки, которые не используют транзакции. Когда пользователь начинает печатать – устанавливается блокировка. Регламентное задание перед тем как начать перепроведение – проверяет что установленных блокировок нет (для всех пользователей). Примеры кода:

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

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

Функция ЕстьБлокировка(Пользователь)
Попытка
Пользователь.ПолучитьОбъект().Заблокировать();
Исключение
Возврат Истина;
КонецПопытки;
Возврат Ложь;
КонецФункции

Функция проверяет для выбранного пользователя, не установлена ли по нему блокировка. Если пользователей много – вызывайте в цикле. Штатная функция Заблокирован() почему-то не отрабатывает. Возможно, фича моей платформы 8.3.11.

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

 

35 Comments

  1. login1020

    такое решение актуально только для печати же?

    А как быть с блокировками и ожиданиями на параллельном проведении Прихода и расхода по одной и той же группе товаров. Есть решение?

    Reply
  2. vasilev2015

    Здравствуйте !

    Это решение позволило не заключать печать в транзакцию.

    Если возникают ошибки из-за одновременного прихода и расхода, то можно таким же способом разделить их по времени.

    Если нужно обязательно выполнять одновременно — используйте стандартные рекомендации для улучшения параллельной работы:

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

    Reply
  3. herfis

    Вполне рабочий костыль. Одобрям!

    Штатная функция Заблокирован() почему-то не отрабатывает

    Прямо в описании функции написано — почему не отрабатывает. Потому что гладиолус.

    Сделали каку и оставалось только ее узаконить 🙂

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

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

    Reply
  4. Goleff74

    Эм. А что за действия такие происходят при печати, что это каким-то образом мешает проведению?

    Reply
  5. vasilev2015

    (4) Там неудачный алгоритм. Документы создаются, проводятся частично, печатаются через модуль объекта. Когда ИТ отдел предлагает все оптимизировать, руководство соглашается. Но чтобы через два-три часа уже все было оптимально 🙂

    Reply
  6. Goleff74

    (5)

    Т.е. во время печати еще и что-то записывается в регистры, которые используются проведением, раз печать в транзакции нежелательно?

    Reply
  7. tormozit
    Регламентное задание перед тем как начать перепроведение – проверяет что установленных блокировок нет (для всех пользователей)

    Так если оно проверило и начало перепроведение, и тут же пользователь начал печать?

    Reply
  8. vasilev2015

    (7) Здравствуйте, Сергей !

    Такая ситуация возможна, но к проблемам не приводит.

    При желании можно поставить проверку и в обратную сторону.

    Reply
  9. ladon

    Я так понимаю, всё это можно было бы решить установкой одного флага на всю систему?

    Например, используя значение регистра постоянных значений. Начал печать — флаг установил. Закончил печать — флаг снял.

    Тогда не пришлось бы по всем пользователям проверять блокировки.

    А так да — неплохой обход.

    Reply
  10. vasilev2015

    (9) Здравствуй, Андрей !

    Рад тебя видеть ))). Это практически наша общая статья )))

    Да, можно было бы выбрать один объект и установить на него пессимистическую объектную блокировку.

    Reply
  11. ladon

    (10)

    Да, можно было бы выбрать один объект и установить на него пессимистическую объектную блокировку.

    Привет-привет.

    Да, память об этой печати будет жить вечно. :))

    Reply
  12. vasilev2015

    (11)

    Да, можно было бы выбрать один объект и установить на него пессимистическую объектную блокировку.

    я сообразил: один глобальный флаг подойдет для других целей, а в данном случае важно, что пользователей много. Первый наложил блокировку, второй не думая о состоянии глобального флага наложил блокировку… Проведение начнется, когда все они освободят ресурс. Получается, что все сделано оптимально. Флагов должно быть много. Все флаги в гости будут к нам и запируем на просторе.

    Reply
  13. ladon

    (12) параллельная печать двумя пользователями.. Ну да, вариант. 🙂

    Reply
  14. PerlAmutor

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

    Reply
  15. vasilev2015

    (14) Здравствуйте !

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

    Reply
  16. PerlAmutor

    (15) Единственная проблема заключается только в том, что свойства пользователя (пароль, логин и т.д.) невозможно изменить на момент печати?

    Reply
  17. Evil Beaver

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

    Reply
  18. vasilev2015

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

    Reply
  19. vasilev2015

    (17) в первую очередь для меня привлекательно отсутствие транзакции по сравнению с «обычными» блокировками. С языками программирования кроме 1С я не знаком, сравнивать не могу. ))

    Reply
  20. PerlAmutor

    А что если повесить блокировку на константу?

    Вот еще один вариант нашел: https://infostart.ru/public/384485/

    Reply
  21. scientia_vinces

    (20) Совсем плохая идея. Если и делать софтовую эмуляцию, то только на основании регистра сведений.

    Reply
  22. vasilev2015

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

    Reply
  23. vasilev2015

    (21) Согласен, использовать внешний файл — совсем плохой вариант. Регистр сведений — чуть лучше плохого варианта, но тоже плох.

    Reply
  24. herfis

    (20) Транзакционную блокировку? Это дорого, неудобно и не всегда допустимо.

    В варианте по ссылке (с файликами) главный минус — неявное ограничение на один рабочий сервер в кластере.

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

    Если мне не изменяет память, в 7.7 пессиместические блокировки объектов реализовывались как раз на файловых блокировках (блокировались соответствующие биты/байты в спец-файликах). В 8-ке, подозреваю, реализовано примерно также, только на компе менеджера кластера и какой-то сервис менеджера кластера отвечает за дистрибуцию этой информации.

    Reply
  25. asved.ru

    Кажется, вернее было бы расследовать причины задержек печати (есть подозрение, что речь о задержке в выводе документа на принтер).

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

    руководство соглашается. Но чтобы через два-три часа уже все было оптимально

    Вы с руководством подходите друг другу.

    Reply
  26. vasilev2015

    (25) Здравствуйте !

    Кажется, вернее было бы расследовать причины задержек печати (есть подозрение, что речь о задержке в выводе документа на принтер).

    у нас при так называемой печати происходит частичное проведение, поэтому взаимоблокировки с процедурой проведения из-за разного порядка записей в регистры. Видно в ТЖ.

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

    Простой тест: один пользователь проводит документ, тормозит в отладчике на последней строке. Второй пользователь проводит документ — взаимоблокировок нет. Параллельное проведение работает. Правильное решение.

    Вы с руководством подходите друг другу.

    Они уважают мой талант, я уважаю их нужды. Лишних денег ни у кого нет.

    Reply
  27. СергейК

    Правильно понимаю, если только один пользователь захочет из под двух своих сессий 1С печатать, то не получится?

    Пока не приходилось делать как бы «множественный» семафор, т.е. не выполнять процедуру пока куча других пользователей делают критические операции. Было наоборот, одна процедура, много пользователей но выполнить её должен кто-то один.

    Интересно, спсб.

    p.s.

    в лоб напрашивается только одна альтернатива: справочник, в который добавляем элемент когда печатаем, удаляем(помечаем) когда закончили. А в регламентном задании запросом проверяем можно ли работать.

    Но так кажется будет накладнее.

    Reply
  28. СергейК

    (21) Почему Константа плохая идея? Или вы не про неё?

    Сейчас, вроде, каждая константа находится в отдельной таблице, блокировка не должна никому мешать…

    Reply
  29. herfis

    (28) Во-первых, все константы находятся мало того, что в одной таблице, так еще и в одной строке 🙂

    Во-вторых, пессиместическую объектную блокировку на константу наложить нельзя. А транзакционная блокировка плоха не только по вышеуказанной причине, но еще и тем что в транзакцию попадают и все остальные операции с БД в задании.

    Любой же семафор на нетранзакционной записи значения в БД плох тем, что он останется взведенным в случае, когда выполнение задания будет прервано аварийно.

    Другое дело, что круг применений таких «мьютексов» в 1С довольно ограничен. Гораздо чаще нужна классическая очередь заданий.

    Reply
  30. vasilev2015

    (27) Здравствуйте !

    Один пользователь, две сессии — эта процедура печати не получится. Альтернативы хуже.

    Reply
  31. WellMaster

    Нормальное решение. Пригодится, спасибо.

    Reply
  32. СергейК

    (29)

    Не нашел ссылки с 1С сайта, но такое уже читал из разных источников, кажется можно верить:

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

    Как это можно проверить, может уже можно?

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

    Reply
  33. herfis

    (32) По-поводу констант ты прав. Заглянул в базу 8.3 с отключенным режимом совместимости — таки по таблице на константу уже. Надо же, а я и не знал. Спасибо за инфу.

    Reply
  34. vasilev2015

    Пункт 2 (Попытка, еще попытка) сильно похож на https://its.1c.ru/db/v8std#content:2149184148:hdoc. Но у меня доступнее, короче и правильно расставлены акценты. )))

    Reply
  35. Casey1984

    К разделу Удачный пример блокировки. Это сработает, если ТекущийПользователь в процедуре печати совпадает с пользователем переданным в ЕстьБлокировка(), т.е. вы последовательно всех пользователей в регламентном задании проведения проверяете? Или я что-то не понял?

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *