0. tormozit 5597 23.03.19 00:31 Сейчас в теме

Безопасная работа с транзакциями во встроенном языке

Разбираемся с опасностями использования транзакций во встроенном языке 1С. Познаем ошибку "В данной транзакции уже происходили ошибки". Учимся защищаться от них.

Перейти к публикации

Комментарии
Избранное Подписка Сортировка: Древо
1. grumagargler 612 24.03.19 17:04 Сейчас в теме
Спасибо за статью!
Покажите пожалуйста пример (псевдо) кода, где разъясняется этот тезис:
Следует иметь ввиду, что такой прием сильно повышает вероятность возникновения ошибок в вызывающем коде, если там были открыты транзакции (текущая является вложенной)

Спасибо.
2. tormozit 5597 24.03.19 18:30 Сейчас в теме
(1) В случае явной внешней транзакции, которая не использует проверку активности транзакции перед ее завершением, будет как показано в таблице из статьи ошибка "Транзакция не активна"
	НачатьТранзакцию();
	// Уровень = 1
	Попытка
		
		НачатьТранзакцию();
		// Уровень = 2
		Попытка
			Запрос = Новый Запрос("ВЫБРАТЬ 1/0");
			Запрос.Выполнить();
			ЗафиксироватьТранзакцию(); 
		Исключение
			// Уровень = 2
			// Завершаем фактическую транзакцию
			Пока ТранзакцияАктивна() Цикл
				ОтменитьТранзакцию();
			КонецЦикла;
			// Уровень = 0
		КонецПопытки;
		
		ЗафиксироватьТранзакцию(); // На входе Уровень = 0. Восстановимая ошибка "Транзакция не активна"
	Исключение
		ОтменитьТранзакцию(); // На входе Уровень = 0. Восстановимая ошибка "Транзакция не активна"
	КонецПопытки;
Показать

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

Также как я уже отметил в статье, есть еще неявные транзакции, которые в общем случае невозможно отличить от явных. Если такой прием применить внутри внешней неявной транзакции, то мы ее отменим. А платформа, когда дойдет до обработки ее завершения, как показано в таблице из статьи выбросит невосстановимое исключение (в демо базе кнопка "Невосстановимая ошибка после отмены транзакции в неявной транзакции"). Ведь платформа не проверяет активность транзакции при завершении неявной транзакции.
Vladimir Litvinenko; +1 Ответить
3. grumagargler 612 24.03.19 20:18 Сейчас в теме
Если же все транзакции в коде написаны с проверкой активности транзакции перед явным завершением, то такой ошибки "Транзакция не активна" не будет

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

Давайте сразу договоримся, цель моя - разобраться. Итак, непарность транзакций, если она есть - она вылезет при любом подходе, и регистрация исключения в журнале нам поможет с ним разобраться (перед отмоткой транзакций). Но если я заблуждаюсь, пожалуйста дайте пример (псевдо) кода где демонстрируется описываемая сложность.
Что бы вам было понятней, что я вообще имею ввиду:
Я считаю, что практически нигде не нужно использовать попытку/исключение при обработке транзакций. Это нужно делать только в тех редких случаях, когда нужно продолжать обработку данных, например в циклах проведения документов. И эти редкие случаи, 1 к 100 в практике работы с транзакциями, а используются в неявных транзакциях, либо используются с возможностью контроля и вызовом метода НачатьТранзакцию после исключения)
4. tormozit 5597 24.03.19 21:27 Сейчас в теме
(3)
// НачатьТранзакцию(); // Эта строка была ошибочно закомментирована
Попытка
	// Что то меняю в БД
	а = 1 / 0;
	ЗафиксироватьТранзакцию();
Исключение
	Пока ТранзакцияАктивна() Цикл
		ОтменитьТранзакцию();
	КонецЦикла;
КонецПопытки;
Показать
Представим, что этом коде вызов НачатьТранзакцию() ошибочно перестал выполняется всегда или при каком то условии. Изменения в БД начали сохраняться - нарушилась логика работы программы. В классическом подходе к отмене транзакции при выполнении ОтменитьТранзакцию() мы получим исключение "Транзакция не активна", которое мы быстро обнаружим и разберемся с ошибкой в коде. В вашем подходе к отмене транзакции ошибки выполнения в такой ситуации этом не возникнет. Программа сможет в ряде случаев еще долго работать, накапливая логические ошибки в данных, пока они не станут заметны пользователям. И расследование проблемы в вашем подходе придется начинать не с конкретной строки в коде, а с анализа всех возможных причин появления соотстветствующих логических ошибок в данных.
Vladimir Litvinenko; +1 Ответить
5. grumagargler 612 24.03.19 22:28 Сейчас в теме
Но ведь тоже самое справедливо и при классическом подходе:
// НачатьТранзакцию(); // Эта строка была ошибочно закомментирована
Попытка
    // Что то меняю в БД
	создатьДокумент ();
    а = 1 / 0;
    ЗафиксироватьТранзакцию();
Исключение
	ОтменитьТранзакцию();
КонецПопытки;

Процедура создатьДокумент ()
	
	созадтьИЗаписать ();
	НачатьТранзакцию ();
    //ЗафиксироватьТранзакцию(); забыли
	
КонецПроцедуры
Показать


Данные в процедуре также будут сохранены и ошибок не будет.
Другими словами, если допускать ошибки парности транзакций - они могут быть допущены везде, ведь нельзя утверждать, что зашаблоненый код устойчивей. Потому что если так - то и Пока ТранзакцияАктивна - тоже зашалонен, только его использования требуется существенно реже.
6. tormozit 5597 24.03.19 22:57 Сейчас в теме
(5) Вы приводите пример, когда в код были внесены две взаимонейтрализующих ошибки. Вероятность такого события на порядок меньше чем внесения одной из них. К тому же считаю, что такой пример не опровергает продемонстированного мной недостатка вашего подхода.
Vladimir Litvinenko; +1 Ответить
7. grumagargler 612 25.03.19 00:25 Сейчас в теме
Вы приводите пример, когда в код были внесены две взаимонейтрализующих ошибки

Я просто решил по максимуму оставить ваш пример. Сделаю проще:
	НачатьТранзакцию();
	Попытка
		создатьДокумент ();
		ЗафиксироватьТранзакцию();
	Исключение
		ОтменитьТранзакцию();
	КонецПопытки;

Процедура создатьДокумент ()
	
	НачатьТранзакцию ();
	создатьИЗаписатьДокумент ();
	// Забыли завершить
	
КонецПроцедуры
Показать

Ошибок нет, данных нет.
К тому же считаю, что такой пример не опровергает продемонстированного мной недостатка вашего подхода.

Ясно, мнения разошлись, всё равно спасибо за потраченное время.
8. tormozit 5597 25.03.19 00:49 Сейчас в теме
(7) В этом случае при возникновении исключения в транзакции состояние данных будет менее корректным в классическом подходе, т.к. последующие операции с БД не будут зафиксированы. Однако исключения при завершении транзакции не будет в обоих подходах. Т.е. ваш подход здесь равнозначен классическому в плане выявления ошибки парности (нет исключения указывающего на нее).
мнения разошлись
Ну это мы с вами проходили уже не раз =)
9. kuzyara 797 25.03.19 09:47 Сейчас в теме
Почему метод НачатьТранзакцию нельзя писать в блоке Попытка-Исключение непосредственно после оператора Попытка?

Как избежать взвода признака “Отмены” менеджера транзакций при обработке исключения внутри транзакции? (при записи подчинённого объекта/обращении к веб-сервису/вызове экспортных процедур записи в бд из других модулей)
10. tormozit 5597 25.03.19 10:15 Сейчас в теме
(9)
Почему метод НачатьТранзакцию нельзя писать в блоке Попытка-Исключение непосредственно после оператора Попытка?
Ну я как бы не утверждал, что нельзя. Такое расположение рекомендуется на ИТС, но его обоснования я не нашел. Поэтому это все же рекомендация, а не требование. Вероятно такое расположение выбрано как наиболее наглядное. Также хорошо, если все будут делать единообразно. Поправил формулировку в статье.
(9)
Как избежать взвода признака “Отмены” менеджера транзакций при обработке исключения внутри транзакции?
Это невозможно сделать. Этот признак устанавливается в коде платформы при ошибках операций с БД.
12. Vladimir Litvinenko 1797 25.03.19 13:11 Сейчас в теме
(10) Это общий стандарт, не только для 1С. В попытке или обработчике исключения должны выполняться действия уже после начала транзакции.

Маловероятно, но что, если исключение будет вызвано непосредственно вызовом НачатьТранзакцию()?
В этом случае мы попадём в обработчик исключения где тут же начнем откатывать транзакцию и получим ещё одну ошибку.

А перед отменой транзакции в обработчике исключения некорректно ставить условие "Если ТранзакцияАктивна()". Об этом уже написали выше, ведь в этом случае мы можем зацепить алгоритмы, находящиеся по стеку выше исполняемого кода и вообще нарушаем модульность программы.

Поэтому действительно целесообразно сначала открывать транзакцию и только потом открывать блок Попытка-Исключение. А в обработчике исключения сразу отменять её без всяких проверок и циклов.
11. Cyberhawk 114 25.03.19 10:33 Сейчас в теме
В раздел "Рекомендуемая структура кода транзакции" предлагаю добавить упоминание, что ребятки из 1С (в типовых конфигурациях) любят крутить отмену транзакции в цикле ("Пока ТранзакцияАктивна() Цикл ОтменитьТранзакцию() КонецЦикла") в транзакциях записи, например, документов, и поэтому наш вызов метода "ОтменитьТранзакцию()" в обработке исключения может выбросить уже необрабатываемое исключение :)
Ну ты об этом вроде и пишешь в другом разделе: "такой прием повышает вероятность возникновения ошибок во внешних транзакциях".
Проще говоря, мой посыл такой: ты в статье упоминаешь (в разделе "Открывать и закрывать транзакцию в одном методе") о том, что наша транзакция может потом начать вызываться вложенно, т.е. типа помни об этом. Но не упоминаешь, что и внутри нашей транзакции потом может появиться код, ломающий изначально задуманную логику. Я бы рекомендовал это упоминание тоже куда-нибудь в статью добавить.
13. Vladimir Litvinenko 1797 25.03.19 13:32 Сейчас в теме
(11)
предлагаю добавить упоминание, что ребятки из 1С (в типовых конфигурациях) любят крутить отмену транзакции в цикле ("Пока ТранзакцияАктивна() Цикл ОтменитьТранзакцию() КонецЦикла") в транзакциях записи, например, документов, и поэтому наш вызов метода "ОтменитьТранзакцию()" в обработке исключения может выбросить уже необрабатываемое исключение

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

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

ifal; artbear; +2 Ответить
14. Cyberhawk 114 25.03.19 14:16 Сейчас в теме
(13) Радует, конечно, что в ЕРП такого добра по пальцам рук можно пересчитать, однако само по себе маленькое количество таких мест не имеет особого значения, т.к. эти методы могут "по цепочке" вызываться из большого количества точек входа в коде конфигурации.
Фигурирование подсистем "Обмен данными" и "Очередь заданий", кажется, уже является поводом задуматься о значительной частоте вызова этих методов.
15. Vladimir Litvinenko 1797 25.03.19 14:40 Сейчас в теме
(14) Да, согласен. Если честно, когда начал искать вхождение такого кода в ERP надеялся, что будет всего один-два случая где-нибудь в подсистемах ЗУП )) Оказалось больше, чем хотелось бы.
16. vasilev2015 1418 25.03.19 15:00 Сейчас в теме
Можно добавить, что внутри явной или неявной транзакции не должно быть ОтправитьПочту(); КопироватьФайл();
?
19. tormozit 5597 25.03.19 16:34 Сейчас в теме
(16) Ну это уже больше относится к транзакционным блокировкам, которые я специально оставил за скобками, т.к. тема очень большая.
17. Vladimir Litvinenko 1797 25.03.19 15:06 Сейчас в теме
Спасибо за демо-базу к публикации! Хорошая коллекция примеров. Тоже такую делал, но здесь больше вариантов рассмотрено, да ещё и с возможностью посмотреть на поведение в фоновом задании.
18. artbear 1158 25.03.19 15:11 Сейчас в теме
(0) Сергей, Обалденная статья.
DoctorRoza; user774630; YPermitin; Dach; jif; json; vasilev2015; +7 Ответить
20. sergathome 26.03.19 14:55 Сейчас в теме
Хорошо систематизировано. Вот это бы всё архитекторам платформы в голову залить, чтоб хоть заболело...
21. tormozit 5597 27.03.19 09:28 Сейчас в теме
В раздел "Скрытая отмена транзакции" добавил метод ЗафиксироватьТранзакциюОбязательно(). В таблицу операций добавил операцию "Завершение потока встроенного языка".
22. shmalevoz 150 27.03.19 10:43 Сейчас в теме
Полезная статья. Небольшое дополнение - при вызове нового исключения удобно включать в него информацию о ранее случившихся исключениях. Например так


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

// Возвращает текст информации об ошибке с учетом прав доступа
//
// Параметры: 
// 	Информация
// 	ТрассировкаВыводить
//
// Возвращаемое значение:
//   Строка
//
Функция ОшибкаИнформацияТекст(Информация, ТрассировкаВыводить = Неопределено) Экспорт
    
	ОшибкаТекст		= "";
	Причина			= Информация;
	ТрассировкаЕсть	= (ТрассировкаВыводить <> Неопределено И ТрассировкаВыводить)
	ИЛИ (ТрассировкаВыводить = Неопределено И ПравоДоступа("Администрирование", Метаданные));
	
	Пока Причина <> Неопределено Цикл
		
		Если ТрассировкаЕсть И НЕ ПустаяСтрока(Причина.ИмяМодуля) Тогда
			ОшибкаТекст	= ОшибкаТекст + ?(ПустаяСтрока(ОшибкаТекст), "", Символы.ПС)
			+ Причина.ИмяМодуля + " {" + Причина.НомерСтроки + "}" + Символы.ПС
			+ Символы.Таб + СокрЛП(Причина.ИсходнаяСтрока);
		КонецЕсли;
		
		ОшибкаТекст	= ОшибкаТекст + ?(ПустаяСтрока(ОшибкаТекст), "", Символы.ПС) 
		+ Причина.Описание;
		
		Причина	= Причина.Причина;
	КонецЦикла;
	
	Возврат ОшибкаТекст;
	
КонецФункции //ОшибкаИнформацияТекст 

Показать
23. tormozit 5597 27.03.19 11:08 Сейчас в теме
(22) Для этого существует намного более удобный вариант оператора ВызватьИсключение - без операнда, т.е.
ВызватьИсключение; 
Он выбрасывает исключение с сохранением оригинальной информации об ошибке.
24. 🅵🅾️🆇 433 04.07.19 12:17 Сейчас в теме
(0) Я использую следующий шаблон (на основе статьи с хабра EvilBeaver)

// ТРАНЗАКЦИЯ +
НачатьТранзакцию();
Попытка
    // ОПЕРАЦИЯ +
    <?>
    // ОПЕРАЦИЯ -
    ЗафиксироватьТранзакцию();
Исключение
    Если ТранзакцияАктивна() Тогда
        ОтменитьТранзакцию();
    КонецЕсли;
    ВызватьИсключение СтрШаблон("Во время транзакции произошла ошибка.
                    |
                    |Описание ошибки: %1", ОписаниеОшибки());
КонецПопытки;
// ТРАНЗАКЦИЯ -
Показать
25. tormozit 5597 04.07.19 13:25 Сейчас в теме
(24) Так делать не всегда неправильно. Поэтому то я и написал эту статью. Более правильной я считаю безусловную отмену транзакции в исключении.
Evil Beaver; acanta; kuzyara; +3 Ответить
26. 🅵🅾️🆇 433 04.07.19 15:35 Сейчас в теме
(25) Тут идея в том, что код может выполняться во "враждебной среде" и потому, данный сниппет является довольно универсальным:
https://habr.com/ru/post/419715/

Подсмотрел у Овсянкина, за что большое ему спасибо :3
27. tormozit 5597 04.07.19 16:31 Сейчас в теме
(26) Кажется в моей статье и комментариях к ней подробно рассмотрены все плюсы и минусы обоих вариантов отмены транзакции. Кстати приведенный тобой вариант отмены фактической транзакции является полумерой и самым надежным (особенно для враждебной среды) является
    Пока ТранзакцияАктивна() Цикл
        ОтменитьТранзакцию();
    КонецЦикла;
как я неоднократно здесь уже описал.
🅵🅾️🆇; +1 Ответить
29. Evil Beaver 6311 10.07.19 18:19 Сейчас в теме
(26) В комментариях к той же статье на Хабре собственно и было разъяснено, что в общем случае мой пример неправильный, а правильный - на ИТС. Но если кругом враги, то мой пример подойдет. Короче, все равно голову надо включать.
🅵🅾️🆇; +1 Ответить
28. DoctorRoza 08.07.19 17:09 Сейчас в теме
Возьму на вооружение. Спасибо
30. Cyberhawk 114 09.09.19 12:00 Сейчас в теме
Также в рамках этой подготовки можно наполнить объектный кэш и кэш представлений ссылок нужными ссылками, но делать это нужно в транзакции
А как?
31. tormozit 5597 09.09.19 12:05 Сейчас в теме
(30) Кэши платформы наполняются автоматически при выполнении соответствующих операций, их использующих. Например для представления ссылки это будет преобразование ссылки к строке.
32. Cyberhawk 114 09.09.19 12:07 Сейчас в теме
(31) Благодарю. Уже добавил такой код (внутри транзакции, в которой осуществляется перелача ссылки в метод записи в ЖР):
Пустышка = "" + МояСсылка

Кажется, не будет лишним добавить твой ответ в статью.
33. tormozit 5597 09.09.19 12:13 Сейчас в теме
(32) Так делать можно, но опасно, т.к. данные в кэше транзакции могут устареть на момент обращения к ним в момент обработки исключения и будет выполнено новое считывание в кэш.
34. Cyberhawk 114 09.09.19 12:21 Сейчас в теме
(33) Да, между получением представления объекта и записью в ЖР может пройти, увы, более 20 секунд.
Особенно это актуально из-за времени ожидания блокировки данных, которое как раз тоже равно 20 секундам (по умолчанию).
Недавно словил как раз такую ошибку.

Что же получается - не существует способа сделать запись в ЖР с "правильными" данными (чтобы при визуальной работе с такою записью ЖР можно было по клику переходить в объект БД, либо чтобы эта запись попадала в отбор ЖР по ссылке), кроме как отмена транзакции (в цикле "Пока ТранзакцияАктивна()") и уже только потом запись в ЖР? :(
35. tormozit 5597 09.09.19 13:26 Сейчас в теме
(34) Кстати по поводу невосстановимой ошибки в методе ЗаписьЖурналаРегистрации при передаче ссылки возможно ее исправили в 8.3.16
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Бизнес-архитектор 1С, ведущий консультант
Санкт-Петербург
Полный день

Руководитель проектов 1С
Санкт-Петербург
Полный день

Программист 1С
Краснодар
зарплата от 80 000 руб. до 160 000 руб.
Полный день

Консультант 1 С
Краснодар
зарплата от 50 000 руб. до 150 000 руб.
Полный день

Консультант-методолог 1С
Краснодар
зарплата от 110 000 руб.
Полный день