В процессе разработки в среде 1С программисты часто сталкиваются с непредвиденными сбоями платформы, которые сложно диагностировать обычными методами отладки. Один из таких критических сбоев — внезапное аварийное завершение работы программы при выполнении метода ЗафиксироватьТранзакцию(), сопровождающееся системным сообщением «Невосстановимая ошибка. Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm...» или аварийным закрытием файлового сеанса.
В этой статье мы подробно разберем, почему возникает эта ошибка, как транзакционный механизм платформы взаимодействует с системными объектами и как правильно спроектировать код, чтобы избежать подобных критических ситуачек в будущем.
Рассмотрим классический сценарий пакетного создания документов. Для обеспечения целостности данных разработчики часто оборачивают создание каждого документа в отдельную транзакцию внутри цикла. Это позволяет изолировать ошибки: если при создании одного документа что-то пошло не так, изменения этой итерации откатываются, а цикл продолжает обрабатывать следующие данные. Шаблон такого кода выглядит следующим образом:
Пока (УсловиеЦикла) Цикл
НачатьТранзакцию();
Рез = СформироватьДокумент();
Если Рез = Ложь Тогда
ОтменитьТранзакцию();
Иначе
ЗафиксироватьТранзакцию();
КонецЕсли;
КонецЦикла;
Такой код может успешно работать на десятках баз данных, но в определенный момент на одной из баз происходит фатальный сбой прямо на строке ЗафиксироватьТранзакцию(). При этом попытка обернуть вызов в конструкцию Попытка — Исключение не приносит результатов: платформа всё равно аварийно завершает работу.
Выясним причину такого поведения. Сбой происходит в тех случаях, когда внутри транзакции бизнес-логики (создания документов, справочников) выполняются операции с системными объектами платформы, в частности, создание или модификация Пользователей информационной базы (объект ПользователиИнформационнойБазы).
Для того чтобы понять физику процесса, нам необходимо проанализировать, как СУБД и платформа 1С работают с таблицами базы данных в момент транзакции.
Во-первых, данные пользователей ИБ хранятся обособленно. В отличие от справочников или документов, которые записываются в стандартные таблицы СУБД, список пользователей информационной базы хранится в специальных системных таблицах. В клиент-серверном варианте это таблица v8users, а в файловом режиме — скрытая системная область внутри единого файла базы данных 1Cv8.1CD.
Во-вторых, в транзакционных механизмах СУБД существует понятие отложенной проверки ограничений (Deferred Constraints). Когда внутри транзакции выполняется метод Записать() для нового пользователя информационной базы, платформа осуществляет лишь первичную валидацию структуры данных. Непосредственная запись и проверка уникальности индексов (например, уникальности имени пользователя в системе) откладываются СУБД до момента окончательной фиксации транзакции.
Когда в коде вызывается метод ЗафиксироватьТранзакцию(), СУБД пытается физически применить изменения из буфера транзакции. Если в этот момент обнаруживается, что имя нового пользователя совпадает с именем уже существующего в системе пользователя, происходит нарушение уникальности индекса (Unique Constraint Violate). С точки зрения СУБД это является **невосстановимой ошибкой**. Транзакция разрушается, а рабочий процесс платформы (или библиотека СУБД dbeng8 в файловом варианте) аварийно завершает свою работу, вызывая обрыв сетевого соединения у тонкого или веб-клиента. В результате пользователь видит системное сообщение об ошибке POST-запроса.
В файловом режиме работы базы данных эта проблема проявляется наиболее остро. Движок файловой СУБД 1С dbeng8 гораздо более чувствителен к транзакционным коллизиям и нарушению логической целостности внутренних кэшей, чем промышленные SQL-серверы (такие как MS SQL Server, PostgreSQL или Oracle Database).
Если в SQL-варианте СУБД при нарушении уникальности индекса может просто вернуть ошибку в приложение и принудительно перевести транзакцию в статус «битая» (в результате чего разработчик получит исключение, которое можно обработать), то в файловом режиме попытка одновременной записи бизнес-данных и системных настроек внутри транзакции часто приводит к моментальному падению процесса.
Для предотвращения подобных сбоев необходимо строго следовать правилам разработки и проектирования системных механизмов.
Правило 1. Разделение бизнес-логики и административных действий
Никогда не выполняйте создание, изменение или удаление пользователей информационной базы внутри транзакций, предназначенных для записи документов или элементов справочников. Операции с пользователями ИБ — это административные действия верхнего уровня. Сначала необходимо полностью отработать логику создания и записи пользователя ИБ (вне транзакции), убедиться в успешности этой операции, и только после этого открывать транзакцию для создания связанных с ним документов.
Правило 2. Обязательная предварительная валидация данных
Перед тем как вызвать метод Записать() для объекта пользователя информационной базы, необходимо программно проверить уникальность его имени. Проанализируем правильный пример реализации такой проверки:
ИмяНовогоПользователя = "ИвановИИ";
НайденныйПользователь = ПользователиИнформационнойБазы.НайтиПоИмени(ИмяНовогоПользователя);
Если НайденныйПользователь = Неопределено Тогда
// Пользователь уникален, можем безопасно создавать
НовыйПользователь = ПользователиИнформационнойБазы.СоздатьПользователя();
НовыйПользователь.Имя = ИмяНовогоПользователя;
НовыйПользователь.ПолноеИмя = "Иванов Иван Иванович";
// Запись происходит вне транзакции документов
НовыйПользователь.Записать();
Иначе
// Пользователь с таким именем уже существует, обрабатываем ситуацию
ВызватьИсключение "Пользователь с именем " + ИмяНовогоПользователя + " уже зарегистрирован в системе!";
КонецЕсли;
Правило 3. Использование механизмов БСП (Библиотеки стандартных подсистем)
Если ваша конфигурация разработана на основе Библиотеки стандартных подсистем (БСП), настоятельно рекомендуется отказаться от прямого использования объекта ПользователиИнформационнойБазы. Для интеграции пользователей в БСП разработан специальный программный интерфейс, завязанный на справочник Пользователи.
Используйте общие модули БСП для работы с пользователями, например:
// Сначала подготавливаем структуру с описанием пользователя ИБ
ОписаниеПользователяИБ = Пользователи.НовоеОписаниеПользователяИнформационнойБазы();
ОписаниеПользователяИБ.Имя = "ИвановИИ";
ОписаниеПользователяИБ.ПолноеИмя = "Иванов Иван Иванович";
// Записываем пользователя через специализированный метод БСП
// Этот метод берет на себя всю предварительную валидацию,
// проверку прав доступа и корректную обработку коллизий имен.
Пользователи.ЗаписатьПользователяИнформационнойБазы(Неопределено, ОписаниеПользователяИБ);
Использование механизмов БСП полностью исключает возникновение невосстановимых ошибок СУБД, так как библиотека проводит многоуровневую валидацию данных на уровне встроенного языка до момента непосредственного обращения к таблицам базы данных.