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

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

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

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

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

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

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

Операция	Выброс исключения	Признак отмены транзакции	Глубина	Фактическая транзакция (СУБД)
Начало записи объекта (неявное начало транзакции)	Если признак отмены был Истина, то “В данной транзакции уже происходили ошибки”	Ложь, если глубина была 0	+1 при программной записи; не меняется при интерактивной записи	Открывается, если глубина была 0
Конец записи объекта (неявный конец транзакции)	Если признак отмены был Истина, то “В данной транзакции уже происходили ошибки” (кнопка "Сломанная неявная транзакция") Если признак отмены был Ложь и стал Истина, то “Не удалось записать <объект>”. Если глубина была 0, то “Ошибка SDBL: Открытых транзакций нет” (кнопка "Отмена транзакции в неявной транзакции")	Истина, если Отказ = Истина или выброшено исключение	-1 при программной записи; не меняется при интерактивной записи	Если глубина стала 0 Фиксируется, если признак отмены стал Ложь. Откатывается, если признак отмены стал Истина.
НачатьТранзакцию		Ложь, если глубина была 0	+1	Открывается, если глубина была 0
ОтменитьТранзакцию	Если глубина была 0, то “Транзакция неактивна”	Истина	-1	Откатывается, если глубина стала 0.
ЗафиксироватьТранзакцию	Если глубина была 0, то “Транзакция неактивна”	не меняется	-1	Если глубина стала 0 Фиксируется, если признак отмены стал Ложь. Откатывается, если признак отмены стал Истина.
Операция (явная или неявная) с БД в транзакции	Если признак отмены был Истина, то “В данной транзакции уже происходили ошибки” восстановимое — для операций без обновления кэша объектного/представлений (кнопка "Ошибка обращения к БД в сломанной явной транзакции") невосстановимое — для операций с обновлением кэша объектного/представлений (кнопка "Невосстановимая ошибка обращения к ссылке в сломанной явной транзакции")	Истина, если выброшено исключение	не меняется	не меняется
Завершение потока встроенного языка			0	Если глубина была > 0, Откатывается

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если же попробовать сделать тот же фокус с интерактивной записью объекта, то на вызове ЗафиксироватьТранзакцию() будет выброшено исключение "Транзакция не активна".

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

44 Comments

grumagargler 24.03.2019 at 17:04

Спасибо за статью!

Покажите пожалуйста пример (псевдо) кода, где разъясняется этот тезис:

Следует иметь ввиду, что такой прием сильно повышает вероятность возникновения ошибок в вызывающем коде, если там были открыты транзакции (текущая является вложенной)

Спасибо.

Reply ↓
tormozit 24.03.2019 at 18:30
(1) В случае явной внешней транзакции, которая не использует проверку активности транзакции перед ее завершением, будет как показано в таблице из статьи ошибка «Транзакция не активна»
```
 НачатьТранзакцию();
// Уровень = 1
Попытка

НачатьТранзакцию();
// Уровень = 2
Попытка
Запрос = Новый Запрос(«ВЫБРАТЬ 1/0»);
Запрос.Выполнить();
ЗафиксироватьТранзакцию();
Исключение
// Уровень = 2
// Завершаем фактическую транзакцию
Пока ТранзакцияАктивна() Цикл
ОтменитьТранзакцию();
КонецЦикла;
// Уровень = 0
КонецПопытки;

ЗафиксироватьТранзакцию(); // На входе Уровень = 0. Восстановимая ошибка «Транзакция не активна»
Исключение
ОтменитьТранзакцию(); // На входе Уровень = 0. Восстановимая ошибка «Транзакция не активна»
КонецПопытки;
```
Показать
Если же все транзакции в коде написаны с проверкой активности транзакции перед явным завершением, то такой ошибки «Транзакция не активна» не будет. Однако возникнет другая проблема — неумышленное нарушение парности открытия/закрытия явных транзакций перестанет приводить к выбросу исключений в местах закрытия транзакций. Нарушение в логике работы программы может сдвинуться дальше и стать менее заметным и разбираться с ним станет в разы сложнее. Т.е. мы избавляемся от одного типа ошибок и получаем другой, более редкий но и более сложный в плане диагностики.

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

Reply ↓
grumagargler 24.03.2019 at 20:18

Если же все транзакции в коде написаны с проверкой активности транзакции перед явным завершением, то такой ошибки «Транзакция не активна» не будет

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

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

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

Что бы вам было понятней, что я вообще имею ввиду:

Я считаю, что практически нигде не нужно использовать попытку/исключение при обработке транзакций. Это нужно делать только в тех редких случаях, когда нужно продолжать обработку данных, например в циклах проведения документов. И эти редкие случаи, 1 к 100 в практике работы с транзакциями, а используются в неявных транзакциях, либо используются с возможностью контроля и вызовом метода НачатьТранзакцию после исключения)

Reply ↓
tormozit 24.03.2019 at 21:27
(3)
```
// НачатьТранзакцию(); // Эта строка была ошибочно закомментирована
Попытка
// Что то меняю в БД
а = 1 / 0;
ЗафиксироватьТранзакцию();
Исключение
Пока ТранзакцияАктивна() Цикл
ОтменитьТранзакцию();
КонецЦикла;
КонецПопытки;
```
Показать
Представим, что этом коде вызов НачатьТранзакцию() ошибочно перестал выполняется всегда или при каком то условии. Изменения в БД начали сохраняться — нарушилась логика работы программы. В классическом подходе к отмене транзакции при выполнении ОтменитьТранзакцию() мы получим исключение «Транзакция не активна», которое мы быстро обнаружим и разберемся с ошибкой в коде. В вашем подходе к отмене транзакции ошибки выполнения в такой ситуации этом не возникнет. Программа сможет в ряде случаев еще долго работать, накапливая логические ошибки в данных, пока они не станут заметны пользователям. И расследование проблемы в вашем подходе придется начинать не с конкретной строки в коде, а с анализа всех возможных причин появления соотстветствующих логических ошибок в данных.

Reply ↓
grumagargler 24.03.2019 at 22:28
Но ведь тоже самое справедливо и при классическом подходе:
```
// НачатьТранзакцию(); // Эта строка была ошибочно закомментирована
Попытка
// Что то меняю в БД
создатьДокумент ();
а = 1 / 0;
ЗафиксироватьТранзакцию();
Исключение
ОтменитьТранзакцию();
КонецПопытки;

Процедура создатьДокумент ()

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

КонецПроцедуры
```
Показать
Данные в процедуре также будут сохранены и ошибок не будет.

Другими словами, если допускать ошибки парности транзакций — они могут быть допущены везде, ведь нельзя утверждать, что зашаблоненый код устойчивей. Потому что если так — то и Пока ТранзакцияАктивна — тоже зашалонен, только его использования требуется существенно реже.

Reply ↓
tormozit 24.03.2019 at 22:57

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

Reply ↓
grumagargler 25.03.2019 at 00:25
Вы приводите пример, когда в код были внесены две взаимонейтрализующих ошибки

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

Процедура создатьДокумент ()

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

КонецПроцедуры
```
Показать
Ошибок нет, данных нет.

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

Ясно, мнения разошлись, всё равно спасибо за потраченное время.

Reply ↓
tormozit 25.03.2019 at 00:49

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

мнения разошлись

Ну это мы с вами проходили уже не раз =)

Reply ↓
kuzyara 25.03.2019 at 09:47

Почему метод НачатьТранзакцию нельзя писать в блоке Попытка-Исключение непосредственно после оператора Попытка?

Как избежать взвода признака “Отмены” менеджера транзакций при обработке исключения внутри транзакции? (при записи подчинённого объекта/обращении к веб-сервису/вызове экспортных процедур записи в бд из других модулей)

Reply ↓
tormozit 25.03.2019 at 10:15

(9)

Почему метод НачатьТранзакцию нельзя писать в блоке Попытка-Исключение непосредственно после оператора Попытка?

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

(9)

Как избежать взвода признака “Отмены” менеджера транзакций при обработке исключения внутри транзакции?

Это невозможно сделать. Этот признак устанавливается в коде платформы при ошибках операций с БД.

Reply ↓
Cyberhawk 25.03.2019 at 10:33

В раздел «Рекомендуемая структура кода транзакции» предлагаю добавить упоминание, что ребятки из 1С (в типовых конфигурациях) любят крутить отмену транзакции в цикле («Пока ТранзакцияАктивна() Цикл ОтменитьТранзакцию() КонецЦикла«) в транзакциях записи, например, документов, и поэтому наш вызов метода «ОтменитьТранзакцию()» в обработке исключения может выбросить уже необрабатываемое исключение 🙂

Ну ты об этом вроде и пишешь в другом разделе: «такой прием повышает вероятность возникновения ошибок во внешних транзакциях«.

Проще говоря, мой посыл такой: ты в статье упоминаешь (в разделе «Открывать и закрывать транзакцию в одном методе«) о том, что наша транзакция может потом начать вызываться вложенно, т.е. типа помни об этом. Но не упоминаешь, что и внутри нашей транзакции потом может появиться код, ломающий изначально задуманную логику. Я бы рекомендовал это упоминание тоже куда-нибудь в статью добавить.

Reply ↓
Vladimir Litvinenko 25.03.2019 at 13:11

(10) Это общий стандарт, не только для 1С. В попытке или обработчике исключения должны выполняться действия уже после начала транзакции.

Маловероятно, но что, если исключение будет вызвано непосредственно вызовом НачатьТранзакцию()?

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

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

Поэтому действительно целесообразно сначала открывать транзакцию и только потом открывать блок Попытка-Исключение. А в обработчике исключения сразу отменять её без всяких проверок и циклов.

Reply ↓
Vladimir Litvinenko 25.03.2019 at 13:32

(11)

предлагаю добавить упоминание, что ребятки из 1С (в типовых конфигурациях) любят крутить отмену транзакции в цикле («Пока ТранзакцияАктивна() Цикл ОтменитьТранзакцию() КонецЦикла») в транзакциях записи, например, документов, и поэтому наш вызов метода «ОтменитьТранзакцию()» в обработке исключения может выбросить уже необрабатываемое исключение

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

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

Reply ↓
Cyberhawk 25.03.2019 at 14:16

(13) Радует, конечно, что в ЕРП такого добра по пальцам рук можно пересчитать, однако само по себе маленькое количество таких мест не имеет особого значения, т.к. эти методы могут «по цепочке» вызываться из большого количества точек входа в коде конфигурации.

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

Reply ↓
Vladimir Litvinenko 25.03.2019 at 14:40

(14) Да, согласен. Если честно, когда начал искать вхождение такого кода в ERP надеялся, что будет всего один-два случая где-нибудь в подсистемах ЗУП )) Оказалось больше, чем хотелось бы.

Reply ↓
vasilev2015 25.03.2019 at 15:00

Можно добавить, что внутри явной или неявной транзакции не должно быть ОтправитьПочту(); КопироватьФайл();

?

Reply ↓
Vladimir Litvinenko 25.03.2019 at 15:06

Спасибо за демо-базу к публикации! Хорошая коллекция примеров. Тоже такую делал, но здесь больше вариантов рассмотрено, да ещё и с возможностью посмотреть на поведение в фоновом задании.

Reply ↓
artbear 25.03.2019 at 15:11

(0) Сергей, Обалденная статья.

Reply ↓
tormozit 25.03.2019 at 16:34

(16) Ну это уже больше относится к транзакционным блокировкам, которые я специально оставил за скобками, т.к. тема очень большая.

Reply ↓
sergathome 26.03.2019 at 14:55

Хорошо систематизировано. Вот это бы всё архитекторам платформы в голову залить, чтоб хоть заболело…

Reply ↓
tormozit 27.03.2019 at 09:28

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

Reply ↓

shmalevoz 27.03.2019 at 10:43

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


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

// Возвращает текст информации об ошибке с учетом прав доступа
//
// Параметры:
//  Информация
//  ТрассировкаВыводить
//
// Возвращаемое значение:
//   Строка
//
Функция ОшибкаИнформацияТекст(Информация, ТрассировкаВыводить = Неопределено) Экспорт

ОшибкаТекст  = «»;
Причина   = Информация;
ТрассировкаЕсть = (ТрассировкаВыводить <> Неопределено И ТрассировкаВыводить)
ИЛИ (ТрассировкаВыводить = Неопределено И ПравоДоступа(«Администрирование», Метаданные));

Пока Причина <> Неопределено Цикл

Если ТрассировкаЕсть И НЕ ПустаяСтрока(Причина.ИмяМодуля) Тогда
ОшибкаТекст = ОшибкаТекст + ?(ПустаяСтрока(ОшибкаТекст), «», Символы.ПС)
+ Причина.ИмяМодуля + » {» + Причина.НомерСтроки + «}» + Символы.ПС
+ Символы.Таб + СокрЛП(Причина.ИсходнаяСтрока);
КонецЕсли;

ОшибкаТекст = ОшибкаТекст + ?(ПустаяСтрока(ОшибкаТекст), «», Символы.ПС)
+ Причина.Описание;

Причина = Причина.Причина;
КонецЦикла;

Возврат ОшибкаТекст;

КонецФункции //ОшибкаИнформацияТекст

Показать

Reply ↓

tormozit 27.03.2019 at 11:08
(22) Для этого существует намного более удобный вариант оператора ВызватьИсключение — без операнда, т.е.
```
ВызватьИсключение; 
```
Он выбрасывает исключение с сохранением оригинальной информации об ошибке.

Reply ↓

🅵🅾️🆇 04.07.2019 at 12:17

(0) Я использую следующий шаблон (на основе статьи с хабра EvilBeaver)

// ТРАНЗАКЦИЯ +
НачатьТранзакцию();
Попытка
// ОПЕРАЦИЯ +
<?>
// ОПЕРАЦИЯ —
ЗафиксироватьТранзакцию();
Исключение
Если ТранзакцияАктивна() Тогда
ОтменитьТранзакцию();
КонецЕсли;
ВызватьИсключение СтрШаблон(«Во время транзакции произошла ошибка.
|
|Описание ошибки: %1», ОписаниеОшибки());
КонецПопытки;
// ТРАНЗАКЦИЯ —