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

Публикация № 1026771

Разработка - Практика программирования

данной транзакции происходили ошибки ОтменитьТранзакцию НачатьТранзакцию ЗафиксироватьТранзакцию

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

Статья актуальна для версии платформы 8.3.14

В этой статье я постарался систематизировать статьи ИТС и собственный опыт в плане обхода опасностей, сопровождающих использование транзакций в 1С. Транзакционные блокировки в статье не рассматриваются. К статье приложена демо база. При ее запуске откроется обычное приложение и форма с кнопками для выполнения примеров, на которые ссылается статья серым шрифтом.

 

Транзакции применяются для целостного изменения связанных данных, т.е. все действия с базой данных, выполняемые в рамках транзакции или выполняются целиком, или целиком откатываются.

 

  1. Менеджер транзакции
    1. Это условное название единого для сеанса базы 1С внутреннего объекта платформы, управляющего транзакцией. Единый для сеанса значит, что он синхронизируется между толстым клиентским и серверным контекстном сеанса.
    2. Свойства менеджера транзакции
      1. Глубина/Вложенность/Счетчик - целое число - сколько раз была открыта транзакция минус сколько раз была закрыта
      2. Отменена – булево - признак отмены транзакции
  2. Вложенные транзакции
    1. Менеджер транзакции содержит свойство “Глубина”. Если оно больше 1, то транзакция считается вложенной.
    2. Логические (1С) и фактические (СУБД) транзакции
      1. Логическая (1С) транзакция - все операции между началом транзакции и следующим завершением транзакции с тем же значением глубины/вложенности/счетчика транзакций
      2. Фактическая (СУБД) транзакция - совпадает с логической транзакцией с Глубина = 1
    3. Вложенными в 1С могут быть только логические транзакции
    4. При начале логической транзакции увеличивается на 1 свойство “Глубина” менеджера транзакции
    5. При завершении логической транзакции уменьшается на 1 свойство “Глубина” менеджера транзакции
    6. Определить во встроенном языке значение свойства Глубина или хотя бы наличие одной вложенности, не изменяя состояние менеджера транзакции, невозможно.
    7. Вложенность транзакций (ИТС)
    8. Правила использования транзакций (ИТС)
  3. Явные и неявные логические транзакции
    1. Явные - начинаются/завершаются методами встроенного языка
      1. НачатьТранзакцию
      2. ЗафиксироватьТранзакцию/ОтменитьТранзакцию
    2. Неявные - начинаются/завершаются платформой в начале/конце выполнения записи объектов данных
    3. Определить во встроенном языке, является ли транзакция явной/неявной, невозможно.
  4. Сломанные транзакции
    1. Менеджер транзакции содержит признак “Отменена”. Сбрасывается он только при начале фактической транзакции. Если он установлен, то транзакция считается сломанной и фактическая транзакция подлежит отмене при ее любом завершении. Устанавливается он при возникновении ошибки базы данных и при вызове ОтменитьТранзакцию().
    2. Определить во встроенном языке, является ли транзакция сломанной, напрямую невозможно, но можно косвенно с достаточной долей уверенности. Пример будет рассмотрен далее.
    3. Примеры ошибок базы данных
      1. Ошибка выполнения запроса
      2. Необработанное исключение при записи объекта
      3. Отказ при записи объекта (“Не удалось записать <объект>”)
      4. Ошибка установки транзакционной блокировки
      5. Ошибка установки объектной блокировки
    4. Ошибки базы данных и транзакции (ИТС)
    5. Невосстановимые и восстановимые исключения (ИТС)
    6. При обращении к БД в сломанной транзакции платформа выбрасывает ошибку “В данной транзакции уже происходили ошибки”. Здесь возникает разрыв между первичной ошибкой, ломающей транзакцию, и этой вторичной ошибкой. Из-за этого разрыва разработчику обычно бывает очень тяжело добраться до причины первичной ошибки. Поэтому к обработке ошибок в сломанной транзакции нужно подходить очень аккуратно. Пример будет рассмотрен далее.
  5. Работа со ссылками в фактической (СУБД) транзакции
    1. Кэш представлений ссылок
      1. Транзакция имеет собственный кэш представлений ссылок.
      2. Обращение к представлению ссылки может вызывать неявное обращение к БД для обновления кэша представления по этой ссылке.
      3. Примеры обращений к представлению ссылки
        1. “” + Ссылка
        2. Таблица.Сортировать(“Ссылка”) - платформа считывает представления ссылок для сортировки по ним
        3. ЗаписьЖурналаРегистрации(,,, Ссылка) - всегда получает представление от ссылки
      4. При обработке исключений в транзакции часто возникает потребность вывода диагностической информации в лог/пользователю. Тут кроется самая коварная особенность сломанной транзакции. При получении представления ссылки с обновлением кэша в сломанной транзакции платформа выбрасывает необрабатываемое исключение без указания исходной строки, в которой выполнено это обращение. Причем если код выполняется внутри неявной транзакции, то исключение является восстановимым, а иначе не восстановимым. Об этом очень неудобном поведении я сообщал в 1С в 2013г и в 2019г, но невосстановимость этой ошибки до сих пор осталась. Далее будет приведен безопасный подход к решению задачи.
    2. Объектный кэш
      1. Транзакция имеет собственный объектный кэш.
      2. Обращение к полю ссылки может вызывать неявное обращение к БД для обновления кэша объекта по этой ссылке.
      3. Примеры обращений к объектному кэшу
        1. Ссылка.ПометкаУдаления;
        2. Ссылка.ПолучитьОбъект();
      4. Аналогично кэшу представлений ссылок при обращении к объектному кэшу в сломанной транзакции платформа может выбрасывать необрабатываемые и невосстановимые исключения, но в меньшем числе ситуаций.
  6. Взаимоблокировка (Deadlock)
    1. Чтобы снизить вероятность появления взаимоблокировок, нужно стараться устанавливать управляемые блокировки, нужные для всех вложенных транзакций, в самом начале фактической (СУБД) транзакции. Тогда выполнение кода установки управляемых блокировок во вложенных транзакциях не будет изменять состав заблокированных ресурсов и тем самым порядок захвата ресурсов в транзакции будет более стабильным и предсказуемым.

 

Таблица операций, воздействующих на менеджер транзакции

 

Операция

Выброс исключения

Признак отмены транзакции

Глубина

Фактическая транзакция (СУБД)

Начало записи объекта (неявное начало транзакции)

Если признак отмены был Истина, то “В данной транзакции уже происходили ошибки”

Ложь, если глубина была 0

+1

Открывается, если глубина была 0

Конец записи объекта (неявный конец транзакции)

  • Если признак отмены был Истина, то “В данной транзакции уже происходили ошибки” (кнопка "Сломанная неявная транзакция")
  • Если признак отмены был Ложь и стал Истина, то “Не удалось записать <объект>”.
  • Если глубина была 0, то “Ошибка SDBL: Открытых транзакций нет(кнопка "Отмена транзакции в неявной транзакции")

Истина, если Отказ = Истина или выброшено исключение

-1

Если глубина стала 0

  • Фиксируется, если признак отмены стал Ложь.
  • Откатывается, если признак отмены стал Истина.

НачатьТранзакцию

 

Ложь, если глубина была 0

+1

Открывается, если глубина была 0

ОтменитьТранзакцию

Если глубина была 0, то “Транзакция неактивна”

Истина

-1

Откатывается, если глубина стала 0.

ЗафиксироватьТранзакцию

Если глубина была 0, то “Транзакция неактивна”

не меняется

-1

Если глубина стала 0

  • Фиксируется, если признак отмены стал Ложь.
  • Откатывается, если признак отмены стал Истина.

Операция (явная или неявная) с БД в транзакции

Если признак отмены был Истина, то “В данной транзакции уже происходили ошибки”

  • восстановимое - для операций без обновления кэша объектного/представлений (кнопка "Ошибка обращения к БД в сломанной явной транзакции")
  • невосстановимое - для операций с обновлением кэша объектного/представлений (кнопка "Невосстановимая ошибка обращения к ссылке в сломанной явной транзакции")

Истина, если выброшено исключение

не меняется

не меняется

Завершение потока встроенного языка     0

Если глубина была > 0, Откатывается

 

Исключение в транзакции

Ошибки в транзакции могут быть

  1. Ломающие - связаны с БД, выставляют признак "Отменена" менеджера транзакции
  2. Неломающие - не связаны с БД, не воздействуют на менеджер транзакции

 

Проверка сломанной транзакции

Хотя явно получить значение признака “Отменена” менеджера транзакции во встроенном языке нельзя. Однако можно воспользоваться косвенным методом - попытаться выполнить простейшую операцию БД (общий модуль ОбщийМодуль1)

// Будет ли выброшено исключение "В данной транзакции уже происходили ошибки" (является ли транзакция сломанной)
Функция ВТранзакцииПроисходилиОшибки() Экспорт 
	Запрос = Новый Запрос("ВЫБРАТЬ 1");
	Попытка
		Запрос.Выполнить();
		Результат = Ложь;
	Исключение
		Результат = Истина;
	КонецПопытки; 
	Возврат Результат;
КонецФункции

При необходимости устранить ложные срабатывания, можно будет еще анализировать описание ошибки. Кстати обращения к серверу СУБД этот запрос не производит (только к модели БД).

 

Подготовка данных для обработки исключения в сломанной транзакции

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

 

Передача ссылки в журнал регистрации в сломанной транзакции

При обработке исключения в сломанной транзакции часто разумно писать диагностическую информацию в журнал регистрации. При этом метод ЗаписьЖурналаРегистрации() неявно берет представление от ссылки, используя кэш представлений ссылок, и помещает его в поле "Представление данных" события журнала. Обращение к этому кэшу в сломанной транзакции несет риск невосстановимой ошибки. Поэтому рекомендую передавать ссылку в журнал регистрации только через эту функцию (общий модуль ОбщийМодуль1)

// Помещение представления ссылки в кэш представлений в сломанной транзакции вызывает досрочное завершение фактической транзакции с невосстановимой ошибкой "В данной транзакции уже происходили ошибки"
// Передача в метод ЗаписьЖурналаРегистрации() ссылки на объект в сломанной транзакции приведет к такому исключению, если представление будет обновлено в кэше.
// Поэтому в таком случае функция возвращает строку идентификатор ссылки. Подразумевается что такие места в коде будут устраняться и потому возвращаться идентификатор будет достаточно редко.
Функция СсылкаДляПередачиВЖурналРегистрации(Ссылка) Экспорт 
	Если ВТранзакцииПроисходилиОшибки() Тогда
		Результат = "" + Ссылка.УникальныйИдентификатор();
	Иначе
		Результат = Ссылка; 
	КонецЕсли; 
	Возврат Результат;
КонецФункции

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

	Исключение
		ОтменитьТранзакцию();
		ЗаписьЖурналаРегистрации("МойОшибка", УровеньЖурналаРегистрации.Ошибка, Ссылка.Метаданные(), СсылкаДляПередачиВЖурналРегистрации(Ссылка));
                ...
	КонецПопытки;

 

Открывать и закрывать транзакцию в одном методе

Старайтесь открывать и закрывать логическую транзакцию в одном методе. Это значительно облегчает отладку и анализ кода. Следствие этой рекомендации - выполнять код транзакции в попытке, чтобы в исключении можно было отменить транзакцию. Иначе исключение поднимется по стеку (в вызывающий метод) без закрытия логической транзакции (восстановления свойства Глубина менеджера транзакции) в текущем методе. Часто и особенно во вложенных транзакциях при обработке такого исключения и после возможной регистрации диагностической информации исключение перевыбрасывают. Даже если на текущий момент ваша транзакция не вызывается вложенно потом это может измениться. Поэтому разумно сразу об этом позаботиться.

 

Операции с БД в сломанной транзакции

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

 

В таком случае может быть оправдано пренебречь рекомендацией "Открывать и закрывать транзакцию в одном методе" и завершить фактическую транзакцию в текущем месте, чтобы сделать возможным выполнение этой важной операции с БД.

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

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

 

Также для выполнения очень важной операции с БД в сломанной транзакции можно использовать запуск фонового задания.

 

Рекомендуемая структура кода транзакции

  • метод НачатьТранзакцию рекомендуется располагать за пределами блока Попытка-Исключение непосредственно перед оператором Попытка;
  • все действия, выполняемые после вызова метода НачатьТранзакцию, должны находиться в одном блоке Попытка, в том числе чтение, блокировка и обработка данных;
  • метод ЗафиксироватьТранзакцию рекомендуется располагать последним в блоке Попытка перед оператором Исключение, чтобы  гарантировать, что после ЗафиксироватьТранзакцию не возникнет исключение;
  • необходимо предусмотреть обработку исключений – в блоке Исключение нужно сначала вызвать метод ОтменитьТранзакцию, а затем выполнять другие действия, если они требуются;
  • рекомендуется в блоке Исключение делать запись в журнал регистрации;
  • в конце блока Исключение рекомендуется добавить оператор ВызватьИсключение

Пример (кнопка "Обработка ошибки в явной транзакции")

Процедура ОбработкаОшибкиВЯвнойТранзакции1() Экспорт 
	НачатьТранзакцию(); // Уровень = 1
	Попытка
		Ссылка = Справочники.БезОбработчиков.Тест1;
		ПредставлениеСсылки = "" + Ссылка; // Подготовка данных для возможной обработки исключения. Это может быть неоправданное обращение к БД. 
		НачатьТранзакцию(); // Уровень = 2
		Попытка
			Запрос = Новый Запрос("ВЫБРАТЬ 1/0");
			Запрос.Выполнить();
			ЗафиксироватьТранзакцию(); // Уровень = 2
		Исключение
			ОтменитьТранзакцию(); // Уровень = 2
			//ЗаписьЖурналаРегистрации("МойОшибка", УровеньЖурналаРегистрации.Ошибка, Ссылка.Метаданные(), Ссылка); // Так получим невосстановимую ошибку, если представления ссылки будет обновлено в кэше
			ЗаписьЖурналаРегистрации("МойОшибка", УровеньЖурналаРегистрации.Ошибка, Ссылка.Метаданные(), СсылкаДляПередачиВЖурналРегистрации(Ссылка));
			Сообщить("Обработана ошибка БД - пытались записать """ + ПредставлениеСсылки + """");
			ВызватьИсключение;
		КонецПопытки;
		ЗафиксироватьТранзакцию(); // Уровень = 1
	Исключение
		ОтменитьТранзакцию(); // Уровень = 1
		Сообщить("Обработана ошибка БД");
		ВызватьИсключение;
	КонецПопытки;
КонецПроцедуры

 

Шаблон транзакции

Создайте себе шаблон текста транзакции (команда "Сервис"/"Шаблоны текста" конфигуратора)

НачатьТранзакцию();
Попытка
	<?>
	ЗафиксироватьТранзакцию();
Исключение
	ОтменитьТранзакцию();
	// Сюда писать код обработки ошибки
	ВызватьИсключение;
КонецПопытки;

 

Скрытая отмена транзакции

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

	НачатьТранзакцию();
	Попытка
		Объект = Справочники.БезОбработчиков.тест1.ПолучитьОбъект();
		Объект.Наименование = ТекущаяДата();
		Объект.Записать();
		Запрос = Новый Запрос("ВЫБРАТЬ 1/0");
		Запрос.Выполнить(); // Ошибка возникла при выполнении операции БД, поэтому установлен признак "Отменена" менеджера транзакции 
	Исключение
		Сообщить("Обработана ошибка БД");
	КонецПопытки;
	ЗафиксироватьТранзакцию(); // Отмена фактической транзакции, т.к. Глубина стала 0 и Отменена = Истина

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

Процедура ЗафиксироватьТранзакциюОбязательно() Экспорт
    Если ВТранзакцииПроисходилиОшибки() Тогда
        ВызватьИсключение "В данной транзакции уже происходили ошибки";
    Иначе
        ЗафиксироватьТранзакцию();
    КонецЕсли;
КонецПроцедуры

Другим примером скрытой отмены транзакции является завершение потока встроенного языка, которое происходит при

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

 

Разрыв неявной транзакции

Этот пример демонстрирует довольно неочевидную возможность разорвать фактическую транзакцию записи объекта. Не рекомендую применять это, однако рекомендую изучить для лучшего понимая всех тонкостей работы транзакций нопка "Разрыв записи объекта", справочник РазрывЗаписиОбъекта модуль Объекта)

Процедура ПередЗаписью(Отказ)
	ЭтотОбъект.Наименование = ТекущаяДата();
	А = Справочники.БезОбработчиков.тест1.ПолучитьОбъект();
	А.Реквизит1 = ТекущаяДата();
	А.Записать();
	Попытка
		Запрос = Новый Запрос("ВЫБРАТЬ 1/0"); 
		Запрос.Выполнить(); // Ошибка возникла при выполении операции БД, поэтому установлен признак "Отменена" менеджера транзакции
	Исключение
	КонецПопытки;
	Если ОбщийМодуль1.ВТранзакцииПроисходилиОшибки() Тогда
		ЗафиксироватьТранзакцию(); // Уменьшили внутреннее свойство "Глубина". Оно стало 0 и установлен признак "Отменена", поэтому фактическая транзакция отменилась.
		// Завершены неявная логическая и фактическая транзакции. Транзакционные блокировки удалены. Изменения объекта ЭтотОбъект пока остались только в памяти.
	КонецЕсли; 
	// Выполняется вне фактической транзакции
	А = Справочники.БезОбработчиков.Тест1.ПолучитьОбъект();
	А.Наименование = ТекущаяДата();
	А.Записать();
        // Изменения объекта А уже зафиксированы, т.к. сделаны вне фактической транзакции
	Если Не ТранзакцияАктивна() Тогда
		НачатьТранзакцию(); // Откроем явную логическую и фактическую транзакции, чтобы внутренная логика фиксации транзакции метода Записать() объекта данных не выбросила исключение
	КонецЕсли; 
КонецПроцедуры

 

Полезные статьи по теме

  1. Правила использования транзакций (ИТС)
  2. Особенности работы объектов при отмене транзакции
  3. Ошибки базы данных и транзакции (ИТС)
  4. Невосстановимые и восстановимые исключения (ИТС)
  5. Вложенность транзакций (ИТС)
  6. Вы не умеете работать с транзакциями (habr)

 

180

Скачать файлы

Наименование Файл Версия Размер
Демо база для статьи
.dt 135,73Kb
23.03.19
6
.dt 135,73Kb 6 Скачать

См. также

Специальные предложения

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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