Проблема с SQLNCLI связанными серверами. «Никакая транзакция не активна

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

Если мы обратимся к технической документации или к диску ИТС, то увидим, что фирма 1С рекомендует следующий способ организации транзакции в попытке

Попытка //1. Начало транзакции. НачатьТранзакцию() ; //2. Блок операций, выполняющихся в транзакции. //3. Если все операции успешны, фиксируем транзакцию. ЗафиксироватьТранзакцию() ; Исключение //4. Если при выполнении кода возникли ошибки, отменяем транзакцию. ОтменитьТранзакцию() ; //5. При необходимости запись в журнал регистрации. //6. При необходимости вывод сообщения пользователю. КонецПопытки ;

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

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

&НаСервереБезКонтекста НачатьТранзакцию() ; //записываем новый товар Товар = Справочники. Товары. СоздатьЭлемент() ; Товар. Наименование = "Дырокол" ; Товар. Записать() ; //записываем цену НаборЗаписей = РегистрыСведений. Цена. СоздатьНаборЗаписей() ; НоваяЗапись = НаборЗаписей. Добавить() ; НоваяЗапись. Период = ТекущаяДата() ; НоваяЗапись. Товар = Товар. Ссылка; НоваяЗапись. Сумма = 100 ; НаборЗаписей. Записать() ; ЗафиксироватьТранзакцию() ; КонецПроцедуры

А теперь поместим транзакцию в блок Попытка Исключение . Скорее всего ошибки могут возникнуть только в момент записи в справочник или в регистр сведений, поэтому предварительную подготовку вынесем за пределы транзакции.

&НаСервереБезКонтекста Процедура ВыполнитьТранзакциюНаСервере() //создаем новый товар Товар = Справочники. Товары. СоздатьЭлемент() ; Товар. Наименование = "Дырокол" ; //Создаем запись с ценой НаборЗаписей = РегистрыСведений. Цена. СоздатьНаборЗаписей() ; НоваяЗапись = НаборЗаписей. Добавить() ; НоваяЗапись. Период = ТекущаяДата() ; НоваяЗапись. Сумма = 100 ; //Выполняем транзакцию в попытке Попытка НачатьТранзакцию() ; Товар. Записать() ; НоваяЗапись. Товар = Товар. Ссылка; НаборЗаписей. Записать() ; ЗафиксироватьТранзакцию() ; Исключение ОтменитьТранзакцию() ; Сообщение = Новый СообщениеПользователю; Сообщение. Текст = ; Сообщение. Сообщить() ; ЗаписьЖурналаРегистрации("Произошла ошибка при записи товара и его цены" ) ; КонецПопытки ; КонецПроцедуры

Как НЕ НАДО делать

У тех кто только начинает работать с транзакциями зачастую возникает желание сделать вот таким образом

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

Или в цикле

НачатьТранзакцию() ; Для каждого Данные Из МассивДанных Цикл Попытка НачатьТранзакцию() ; Данные. Записать() ; ЗафиксироватьТранзакцию() ; Исключение ОтменитьТранзакцию() ; КонецПопытки ; КонецЦикла ; ЗафиксироватьТранзакцию() ;

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

&НаСервереБезКонтекста Процедура ВыполнитьТранзакциюНаСервере() НачатьТранзакцию() ; Попытка НачатьТранзакцию() ; Товар = Справочники. Товары. СоздатьЭлемент() ; Товар. Наименование = "Стол" ; Товар. Записать() ; ВызватьИсключение "Ошибка записи товара." ; ЗафиксироватьТранзакцию() ; Исключение ОтменитьТранзакцию() ; Сообщение = Новый СообщениеПользователю; Сообщение. Текст = ОписаниеОшибки() Попытка НачатьТранзакцию() ; Товар = Справочники. Товары. СоздатьЭлемент() ; Товар. Наименование = "Стул" ; Товар. Записать() ; ЗафиксироватьТранзакцию() ; Исключение ОтменитьТранзакцию() ; Сообщение = Новый СообщениеПользователю; Сообщение. Текст = ОписаниеОшибки() ; Сообщение. Сообщить() ; КонецПопытки ; ЗафиксироватьТранзакцию() ; КонецПроцедуры

В результате выполнения этой процедуры увидим в окне сообщений следующее:

{ВнешняяОбработка.ТранзакцииВПопытке.Форма.Форма.Форма(20)}: Ошибка записи товара. {ВнешняяОбработка.ТранзакцииВПопытке.Форма.Форма.Форма(40)}: Ошибка при вызове метода контекста (Записать): В данной транзакции уже происходили ошибки!

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

Возможные варианты

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

&НаСервереБезКонтекста Процедура ВыполнитьТранзакциюНаСервере() // Начинаем транзакцию Отказ = Ложь ; НачатьТранзакцию() ; // Пытаемся записать товар Попытка Товар = Справочники. Товары. СоздатьЭлемент() ; Товар. Наименование = "Дырокол" ; Товар. Записать() ; Исключение Отказ = Истина ; Сообщение = Новый СообщениеПользователю; Сообщение. Текст = "Ошибка при записи товара" ; Сообщение. Сообщить() ; КонецПопытки ; // Пытаемся записать цену Попытка НаборЗаписей = РегистрыСведений. Цена. СоздатьНаборЗаписей() ; НоваяЗапись = НаборЗаписей. Добавить() ; НоваяЗапись. Период = ТекущаяДата() ; НоваяЗапись. Товар = Товар. Ссылка; НоваяЗапись. Сумма = 100 ; НаборЗаписей. Записать() ; Исключение Отказ = Истина ; Сообщение = Новый СообщениеПользователю; Сообщение. Текст = "Ошибка при записи цены" ; Сообщение. Сообщить() ; КонецПопытки ; // Фиксируем или отменяем транзакцию Если НЕ Отказ Тогда ЗафиксироватьТранзакцию() ; Иначе ОтменитьТранзакцию() ; КонецЕсли ; КонецПроцедуры

Аналогичным образом можно поступить и когда мы перебираем и записываем какие-либо данные в цикле. В этом случае мы сможем получить перечень всех данных с ошибками, если такие будут.

Заголовок вышел броским, но накипело. Сразу скажу, что речь пойдет об 1С. Дорогие 1С-ники, вы не умеете работать с транзакциями и не понимаете что такое исключения. К такому выводу я пришел, просматривая большое количество кода на 1С, рождаемого в дебрях отечественного энтерпрайза. В типовых конфигурациях с этим все достаточно хорошо, но ужасающее количество заказного кода написано некомпетентно с точки зрения работы с базой данных. Вы когда-нибудь видели у себя ошибку "В данной транзакции уже происходили ошибки"? Если да - то заголовок статьи относится и к вам. Давайте под катом разберемся, наконец, что такое транзакции и как правильно с ними обращаться, работая с 1С.

Почему надо бить тревогу

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

Почему это плохо? Потому что данная ошибка ничего не говорит вам о том, где на самом деле случилась проблема. Когда в саппорт от пользователя приходит скриншот с таким текстом, а в особенности для серверного кода, с которым интерактивно не работает человек - это… Хотел написать "критичная ошибка", но подумал, что это buzzword, на который уже никто не обращает внимания…. Это задница. Это ошибка программирования. Это не случайный сбой. Это косяк, который надо немедленно переделывать. Потому что, когда у вас фоновые процессы сервера встанут ночью и компания начнет стремительно терять деньги, то "В данной транзакции уже происходили ошибки" это последнее, что вы захотите увидеть в диагностических логах.

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

Что такое транзакции в 1С

Неловко писать про азбучные истины, но, видимо, немножго придется. Транзакции в 1С - это то же самое, что транзакции в СУБД. Это не какие-то особенные "1С-ные" транзакции, это и есть транзакции в СУБД. Согласно общей идее транзакций, они могут либо выполниться целиком, либо не выполниться совсем. Все изменения в таблицах базы данных, выполненные внутри транзакции, могут быть разом отменены, как будто ничего не было.

Далее, нужно понимать, что в 1С не поддерживаются вложенные транзакции. Собственно говоря, они не поддерживаются не "в 1С", а вообще не поддерживаются. По-крайней мере, теми СУБД, с которыми умеет работать 1С. Вложенных транзакций, например, нет в MS SQL и Postgres. Каждый "вложенный" вызов НачатьТранзакцию просто увеличивает счетчик транзакций, а каждый вызов "ЗафиксироватьТранзакцию" - уменьшает этот счетчик. Данное поведение описано в множестве книжек и статей, но выводы из этого поведения, видимо, разобраны недостаточно. Строго говоря, в SQL есть т.н. SAVEPOINT, но 1С их не использует, да и вещь это достаточно специфичная.

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

Код на английском

На самом деле, нет. Мне совершенно не хочется дублировать примеры на английском только ради того, чтобы потешить любителей холиваров и священных войн.

Вы же наверняка пишете такой код, да? Приведенный пример кода содержит ошибки. Как минимум, три. Знаете какие? Про первую я скажу сразу, она связана с объектными блокировками и не имеет отношения непосредственно к транзакциям. Про вторую - чуть позже. Третья ошибка - это deadlock, который возникнет при параллельном исполнении этого кода, но это тема для отдельной статьи, ее рассматривать сейчас не будем, дабы не усложнять код. Ключевое слово для гугления: deadlock управляемые блокировки .

Обратите внимание, простой ведь код. Такого в ваших 1С-системах просто вагон. И он содержит сразу, как минимум, 3 ошибки. Задумайтесь на досуге, сколько ошибок есть в более сложных сценариях работы с транзакциями, написанных вашими программистами 1С:)

Объектные блокировки

Итак, первая ошибка. В 1С существуют объектные блокировки, так называемые "оптимистические" и "пессимистические". Кто придумал термин, не знаю, убил бы:). Совершенно невозможно запомнить, какая из них за что отвечает. Подробно про них написано и , а также в прочей IT-литературе общего назначения.

Суть проблемы в том, что в указанном примере кода изменяется объект базы данных, но в другом сеансе может сидеть интерактивный пользователь (или соседний фоновый поток), который тоже будет менять этот объект. Здесь один из вас может получить ошибку "запись была изменена или удалена". Если это произойдет в интерактивном сеансе, то пользователь почешет репу, ругнется и попробует переоткрыть форму. Если это произойдет в фоновом потоке, то вам придется искать это в логах. А журнал регистрации, как вы знаете, медленный, а ELK-стек для журналов 1С у нас в отрасли настраивают единицы… (мы, к слову, входим в число тех, кто настраивает и другим помогает настраивать:))

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

А теперь про транзакции

С первой ошибкой разобрались, давайте перейдем ко второй.

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

Именно так я бы назвал эту проблему. В нашем статическом анализаторе кода 1С на базе SonarQube мы даже отдельно встроили такую диагностику. Сейчас я работаю над ее развитием, и фантазия программистов 1С, чей код попадает ко мне на анализ, порой приводит меня в шок и трепет…

Почему? Потому что выброшенное наверх исключение внутри транзакции в 90% случаев не даст эту транзакцию зафиксировать и приведет к ошибке. Следует понимать, что 1С автоматически откатывает незавершенную транзакцию только после возвращения из скриптового кода на уровень кода платформы. До тех пор, пока вы находитесь на уровне кода 1С, транзакция остается активной.

Поднимемся на уровень выше по стеку вызовов:

Процедура ВажныйКод() СписокСсылок = ПолучитьГдеТоСписокСсылок(); ОченьПолезныйИВажныйКод(СписокСсылок); КонецПроцедуры

Смотрите, что получается. Наш проблемный метод вызывается откуда-то извне, выше по стеку. На уровне этого метода разработчик понятия не имеет - будут ли какие-то транзакции внутри метода ОченьПолезныйИВажныйКод или их не будет. А если будут - то будут ли они все завершены… Мы же все тут за мир и инкапсуляцию, верно? Автор метода "ВажныйКод" не должен думать про то, что именно происходит внутри вызываемого им метода. Того самого, в котором некорректно обрабатывается транзакция. В итоге, попытка поработать с базой данных после выброса исключения изнутри транзакции, с высокой вероятностью приведет к тому, что "В данной транзакции бла-бла…"

Размазывание транзакций по методам

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

Например:

Процедура ВажныйКод() СписокСсылок = ПолучитьГдеТоСписокСсылок(); ОченьПолезныйИВажныйКод(СписокСсылок); ЗафиксироватьТранзакцию(); // Путевка в ад, серьезный разговор с автором о наших сложных трудовых отношениях. КонецПроцедуры

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

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

Пытаемся исправить код

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

Первый подход типичного 1С-ника

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

Процедура ОченьПолезныйИВажныйКод(СписокСсылокСправочника) НачатьТранзакцию(); Для Каждого Ссылка Из СписокСсылокСправочника Цикл ОбъектСправочника = Ссылка.ПолучитьОбъект(); ОбъектСправочника.КакоеТоПоле = "Я изменен из программного кода"; Попытка ОбъектСправочника.Записать(); Исключение Лог.Ошибка("Не удалось записать элемент %1", Ссылка); Продолжить; КонецПопытки; КонецЦикла; ЗафиксироватьТранзакцию(); КонецПроцедуры

Ну как, стало лучше, да? Ведь теперь, возможные ошибки записи обрабатываются и даже логируются. Исключения больше не возникнут при записи объекта. И в логе даже видно - на каком объекте, не поленился, вывел в сообщение ссылку вместо лаконичного "Ошибка записи справочника", как это часто любят писать вечно торопящиеся разработчики. Иными словами, налицо забота о пользователе и рост компетенций.

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

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

Код, который начинает транзакцию, обязан завершить или откатить ее. Не взирая ни на какие исключения. Каждая ветка кода должна быть исследована на предмет выхода из метода без фиксации или отмены транзакции.

Методы работы с транзакциями в 1С

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

НачатьТранзакцию()
ЗафиксироватьТранзакцию()
ОтменитьТранзакцию()
ТранзакцияАктивна()

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

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

Как правильно пользоваться этими методами? Очень просто: надо прочитать сформулированное выше правило:

Как же соблюсти это правило? Давайте попробуем:

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

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

Отлично, мы поймали возникающую ошибку, но что с ней делать? Записать сообщение в лог? Ну, может быть, если код логирования ошибок должен быть именно на этом уровне и ошибку мы тут ждем. А если нет? Если мы не ожидали тут никаких ошибок? Тогда мы должны просто передать это исключение выше, пусть с ними разбирается другой слой архитектуры. Делается это оператором "ВызватьИсключение" без аргументов. В этих ваших джава-сиплюсплюсах это делается точно так же оператором throw.

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

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

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

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

Финальный вариант

Наконец, мы можем написать правильный, "транзакционно-безопасный" вариант кода. Вот он:

**UPD: в комментариях предложен более безопасный вариант, когда ЗафиксироватьТранзакцию расположен внутри блока Попытка. Здесь приведен именно этот вариант, ранее Фиксация располагалась после блока Попытка-Исключение.

НачатьТранзакцию(); Попытка ДелаемЧтоТо(); ЗафиксироватьТранзакцию(); Исключение Если ТранзакцияАктивна() Тогда ОтменитьТранзакцию(); КонецЕсли; ВызватьИсключение; КонецПопытки;

Постойте, но ведь не только "ОтменитьТранзакцию" может выдавать ошибки. Почему же тогда "ЗафиксироватьТранзакцию" не обернут в такое же условие с "ТранзакцияАктивна"? Опять же, по тому же самому правилу: код, начавший транзакцию, должен нести ответственность за ее завершение. Наша транзакция необязательно самая первая, она может быть вложенной. На нашем уровне абстракции мы обязаны заботиться только о нашей транзакции. Все прочие должны быть нам неинтересны. Они чужие, мы не должны нести за них ответственность. Именно НЕ ДОЛЖНЫ. Нельзя предпринимать попыток выяснения реального уровня счетчика транзакций. Это опять нарушит инкапсуляцию и приведет к "размазыванию" логики управления транзакциями. Мы проверили активность только в обработчике исключения и только для того, чтобы убедиться, что наш обработчик не породит нового исключения, "прячущего" старое .

Чек-лист рефакторинга

Давайте рассмотрим несколько наиболее распространенных ситуаций, требующих вмешательства в код.

Паттерн:

НачатьТранзакцию(); ДелаемЧтоТо(); ЗафиксироватьТранзакцию();

Обернуть в "безопасную" конструкцию с Попыткой, Проверкой активности и пробросом исключения.

Паттерн:

Если Не ТранзакцияАктивна() Тогда НачатьТранзакцию() КонецЕсли

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

Примерно похожий вариант:

Если ТранзакцияАктивна() Тогда ЗафиксироватьТранзакцию() КонецЕсли

аналогично: фиксация транзакции по условию - это странно. Почему тут условие? Что, кто-то иной мог уже зафиксировать эту транзакцию? Повод для разбирательства.

Паттерн:

НачатьТранзакцию() Пока Выборка.Следующий() Цикл // чтение объекта по ссылке // запись объекта КонецЦикла; ЗафиксироватьТранзакцию();

ввести управляемую блокировку во избежание deadlock
ввести вызов метода Заблокировать
обернуть в "попытку", как показано выше

Паттерн:

НачатьТранзакцию() Пока Выборка.Следующий() Цикл Попытка Объект.Записать(); Исключение Сообщить("Не получилось записать"); КонецПопытки; КонецЦикла; ЗафиксироватьТранзакцию();

Данная транзакция уже не завершится в случае исключения. Нет смысла продолжать цикл. Код требуется переписать, сверяясь с исходной задачей. Дополнительно обеспечить более информативное сообщение об ошибке.

В заключение

Я, как вы уже, наверное, догадались, отношусь к людям, любящим платформу 1С и разработку на ней. К платформе, разумеется, есть претензии, особенно в среде Highload, но в общем и целом, она позволяет недорого и быстро разрабатывать очень качественные корпоративные приложения. Давая из коробки и ORM, и GUI, и веб-интерфейс, и Reporting, и много чего еще. В комментариях на Хабре обычно пишут всякое высокомерное, так вот, ребята - основная проблема 1С, как экосистемы - это не платформа и не вендор. Это слишком низкий порог вхождения, который позволяет попадать в отрасль людям, не понимающим, что такое компьютер, база данных, клиент-сервер, сеть и всякое такое. 1С сделала разработку корпоративных приложений слишком легкой. Я за 20 минут могу написать на ней учетную систему для закупок/продаж с гибкими отчетами и веб-клиентом. После этого, мне несложно подумать о себе, что и на больших масштабах можно писать примерно так же. Как-то там 1С сама все внутри сделает, не знаю как, но наверное сделает. Напишу-ка я "НачатьТранзакцию()"....

Добавить метки

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

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

Система «1С:Предприятие» осуществляет неявный вызов транзакций при выполнении любых действий, связанных с модификацией информации, хранящейся в базе данных. Например, все обработчики событий, расположенные в модулях объектов и наборов записей, связанные с модификацией данных базы данных, вызываются в транзакции. В транзакции выполняется также чтение объектов следующих типов: ПланОбменаОбъект, ДокументОбъект, СправочникОбъект, ПланВидовХарактеристикОбъект, ПланВидовРасчетаОбъект, ПланСчетовОбъект, БизнесПроцессОбъект, ЗадачаОбъект, ПоследовательностьНаборЗаписей, РегистрСведенийНаборЗаписей, РегистрНакопленияНаборЗаписей, РегистрБухгалтерииНаборЗаписей, РегистрРасчетаНаборЗаписей, ПерерасчетНаборЗаписей . При этом в режиме управляемых блокировок выполняется установка разделяемой блокировки по значению регистратора для наборов записей и по значениям отбора для набора записей независимого регистра сведений.

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

Использование явного вызова транзакций

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

● при окончании выполнения встроенного языка (обработчик события, внешнее соединение, automation-сервер);

● при передаче управления с сервера на клиента.

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

Попытка

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

// Последовательность операторов

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

Исключение

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

КонецПопытки;

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

● невосстановимые,

● восстановимые.

Невосстановимые ошибки - это ошибки, при возникновении которых нормальное функционирование системы «1С:Предприятие» может быть нарушено, например, могут быть испорчены данные. При возникновении невосстановимой ошибки выполнение системы «1С:Предприятие» прекращается в любом случае. Если невосстановимая ошибка произошла в процессе выполнения транзакции, то все изменения, сделанные в рамках этой транзакции, отменяются системой.

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

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

Вложенный вызов транзакций

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

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

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

// Вложенный вызов транзакции

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

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

Однако подобное обращение не означает начала новой транзакции в рамках уже выполняющейся.

ВНИМАНИЕ! Система «1С:Предприятие» не поддерживает вложенных транзакций. Это означает, что всегда действует только транзакция самого верхнего уровня.

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

Влияние транзакций на работу программных объектов

В общем случае программные объекты, используемые системой «1С:Предприятие», абсолютно «прозрачны» для транзакций базы данных. Иначе говоря, транзакции базы данных могут вызываться при выполнении различных методов программных объектов, однако, например, действия, выполняемые базой данных при откате транзакции, в общем случае никак не влияют на соответствующие программные объекты.

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

В этом правиле есть исключения. В силу значительной прикладной специфики программных объектов системы «1С:Предприятие» в некоторых случаях откат изменений, выполненных в базе данных, все же может влиять на значения свойств соответствующих программных объектов. Это происходит в следующих случаях:

● при отмене транзакции признак проведения документа восстанавливает значение, которое было до начала транзакции;

● если объект был создан и записан в транзакции, то при откате транзакции очищается значение ссылки;

● если объект создавался вне транзакции и при записи его в транзакции использовался код/номер, сгенерированный автоматически, то при отмене транзакции код/номер очищается.

install create (4)

cursor = connection . cursor () cursor . executemany ("insert into person(firstname, lastname) values (?, ?)" , persons ) connection . commit ()

Я пытаюсь закодировать индексатор книг, используя Python (традиционный, 2.7) и SQLite (3).

Код сводится к этой последовательности операторов SQL:

"select count(*) from tag_dict" () /* [(30,)] */ "select count(*) from file_meta" () /* [(63613,)] */ "begin transaction" () "select id from archive where name=?" ("158326-158457.zip" ,) /* [(20,)] */ "select id from file where name=? and archive=?" ("158328.fb2" , 20 ) /* [(122707,)] */ "delete from file_meta where file=?" (122707 ,) "commit transaction" () # error: cannot commit - no transaction is active

Уровень изоляции «DEFERRED» («ЭКСКЛЮЗИВ» не лучше).

Я попытался использовать connection.commit () вместо cursor.execute ("commit") - ничего полезного не произошло.

Конечно, я искал и Net, но найденные ответы не имеют значения.
Режим автокомпозиции неприемлем по причине производительности.
Я использую только файл базы данных за раз.
Мой код работает в одном потоке.
Все выполнение SQL выполняется с помощью единственной функции, которая гарантирует, что я могу одновременно открыть не более одного курсора.

Итак, что случилось с транзакцией здесь?

Если я использую connection.commit () (обратите внимание: нет метода connection.begin!), Тогда я просто теряю свои данные.

Конечно, у меня есть doube / triple / quaruple проверенные разрешения файлов в файле базы данных и его каталоге.

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

Как новичок, я не могу ответить на свой вопрос в течение 8 часов... Итак, андер теперь есть:

Решение было и состоит из единственной идеи.

Я пытаюсь выполнить хранимую процедуру и просто вставлять ее результаты во временную таблицу, и я получаю следующее сообщение:

Операция не может быть выполнена, поскольку поставщик OLE DB «SQLNCLI» для связанного сервера «MyServerName» не смог начать распределенную транзакцию. Поставщик OLE DB «SQLNCLI» для связанного сервера «MyServerName» возвратил сообщение «Никакая транзакция не активна».

Мой запрос выглядит так:

INSERT INTO #TABLE EXEC MyServerName.MyDatabase.dbo.MyStoredProcedure Param1, Param2, Param3

Точный номер столбца, имена, проблема не является результатом.

MSDTC разрешен и запущен на обоих компьютерах, также вызывает удаленную процедуру.

Машины не находятся в одном домене, но я могу выполнять удаленные запросы с моей машины и получать результат. Я даже могу выполнить хранимую процедуру и увидеть ее результаты, я просто не могу вставить ее в другую таблицу.

Помоги пожалуйста? :)

<�Сильный> ИЗМЕНИТЬ

О, я забыл упомянуть, хранимая процедура не срабатывает. Он только вставляет записи во временные таблицы, которые он создает для обработки данных.

3 ответы

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

Сегодня нам пришлось принудительно перезагрузить компьютер на нашем сервере разработки из-за неисправности без разрыва, и когда мы загрузили сервер, угадайте, что? Оно работает!

Поэтому для записи я изменил определенную конфигурацию MSDTC, добавил ее как связанный сервер и разрешил RPC IN и OUT, а также изменил конфигурацию RPC для «НЕТ АУТЕНТИФИКАЦИИ ТРЕБУЕТСЯ» или что-то в этом роде.

Я помню, где-то читал, что после изменения этой конфигурации требуется перезагрузка, хотя Windows говорит, что она уже перезапустила службу.

Я перезагрузил свой сервер, как... дважды, так как я его изменил, и он все еще не работает. Но как сегодня, после полного отключения и включения, это работает!

Что касается синтаксиса, я сохранил то же самое.

Вы также должны проверить разрешение имен DNS в конфигурации IP-сети.

Например, у вас есть сервер под названием server-a.mydomain.com, а другой - server-b.otherdomain.com, войдите в сервер-a и выполните «ping-server-b» (без домена).

Если он отвечает: «Запрос Ping не смог найти хост-сервер-b. Пожалуйста, проверьте имя и повторите попытку». это проблема.

Go to the Control Pannel > Network Connections > Right click in the network card > properties > Internet Protocol > Properties > Advanced > DNS > Append this DNS suffix in order. And here add the local domain: mydomain.com and then add the remote domain: otherdomain.com Click OK until you exit

Теперь, если вы выполняете «ping-server-b», он должен отвечать на что-то вроде.