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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

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

Показать
23. tormozit 5328 27.03.19 11:08 Сейчас в теме
(22) Для этого существует намного более удобный вариант оператора ВызватьИсключение - без операнда, т.е.
ВызватьИсключение; 
Он выбрасывает исключение с сохранением оригинальной информации об ошибке.
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Программист 1С
Самара
зарплата от 50 000 руб. до 100 000 руб.
По совместительству


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

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

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