Каждый администратор и разработчик 1С сталкивался с ситуацией, когда два пользователя одновременно пытаются открыть и отредактировать один и тот же документ. В штатном режиме система должна мягко предупредить второго пользователя о том, что объект заблокирован, и предложить открыть его в режиме чтения. Однако в некоторых случаях вместо аккуратного диалогового окна программа аварийно завершает сеанс, выбрасывая критическое системное окно с предложением «Завершить работу» или «Перезапустить».
В этой статье мы подробно разберем, почему возникает такое агрессивное поведение платформы «1С:Предприятие 8.3», как на это влияют доработки конфигурации, режим совместимости и особенности работы СУБД MS SQL. Мы выработаем пошаговый алгоритм локализации и устранения этой проблемы.
Для начала проанализируем, как работает стандартный механизм защиты данных в 1С. Когда пользователь открывает форму существующего документа и начинает вносить изменения, платформа накладывает на этот объект так называемую пессимистическую блокировку. Ее цель — гарантировать, что пока один человек редактирует данные, никто другой не сможет их перезаписать и нарушить целостность базы данных.
Если в этот момент второй пользователь открывает ту же форму и пытается что-то изменить, платформа выполняет системный вызов и обнаруживает активную блокировку. В нормальных условиях срабатывает внутренний обработчик исключений платформы:
"Объект заблокирован пользователем [ИмяПользователя]...".Однако при определенных обстоятельствах этот обработчик исключений "ломается". Ошибка объектной блокировки на уровне СУБД или сервера приложений воспринимается платформой как критический крах сеанса. Выясним основные причины такого поведения.
Рассмотрим классический пример — конфигурацию «Управление производственным предприятием» (УПП 1.3). Данное решение разработано на обычных формах и изначально проектировалось под стандарты платформы «1С:Предприятие 8.2».
Когда разработчики в процессе адаптации и обновления под платформу 8.3 полностью отключают в свойствах конфигурации режим совместимости (устанавливают значение Не использовать), кардинально меняются внутренние алгоритмы работы платформы:
ИзменяетДанные. При отключенном режиме совместимости любая попытка интерактивного изменения такого элемента (даже просто щелчок мыши или попытка активизировать строку) мгновенно инициирует транзакционную блокировку на уровне базы данных. Если объект уже занят другим сеансом, это вызывает моментальный конфликт блокировок, который платформа не успевает обработать "мягко", что приводит к падению интерфейса.Проанализируем технологические особенности самой платформы. В истории релизов 1С:Предприятие 8.3 (особенно в ветках 8.3.9, 8.3.10, 8.3.11, а также в некоторых сборках 8.3.12 и 8.3.15) присутствовали зарегистрированные платформенные ошибки.
Суть багов заключалась в том, что при возникновении конфликта объектных блокировок на сервере приложений под управлением MS SQL Server или PostgreSQL, СУБД возвращала ошибку ожидания блокировки. Из-за некорректной обработки этого кода возврата в самом ядре платформы 1С, рабочий процесс rphost разрывал соединение с клиентским приложением. Клиент получал критическое исключение, которое невозможно обработать на уровне встроенного языка, и падал с предложением перезапуска.
Иногда разработчики пытаются самостоятельно управлять блокировками в коде модулей форм или объектов. Рассмотрим типичный пример небезопасного кода:
Попытка
ДокументОбъект.Заблокировать();
Исключение
Предупреждение("Документ сейчас редактируется другим сотрудником!");
КонецПопытки;
На проблемных релизах платформы (или при отключенном режиме совместимости) метод Заблокировать() в случае неудачи порождает низкоуровневую ошибку ядра. Эта ошибка буквально "пробивает" конструкцию Попытка ... Исключение. Участок кода Исключение просто игнорируется, управление не передается интерпретатору 1С, и операционная система аварийно закрывает клиентский сеанс.
Если у пользователей часто аварийно завершается работа (например, из-за проблем с сетью, закрытия терминальных сессий по таймауту или перезапуска процессов сервера 1С), в базе данных MS SQL могут оставаться так называемые "фантомные" транзакции и блокировки записей.
При попытке живого пользователя открыть такой документ система натыкается на блокировку, владельца которой (сеанса) в реальности уже нет на сервере 1С. Не имея возможности сопоставить блокировку с активным пользователем, менеджер блокировок дает сбой, вызывая критическую системную ошибку.
---
Разберем последовательность действий, которая поможет вернуть стабильную работу пользователям и восстановить штатный механизм предупреждений о блокировках.
Шаг 1. Анализ и восстановление режима совместимости
Если вы работаете на конфигурации с обычными формами (УПП 1.3, УТ 10.3, КА 1.1) и столкнулись с этой проблемой после обновления платформы, выполните следующие действия:
Не использовать, верните значение, рекомендованное разработчиком конфигурации (например, Версия 8.2.13).Шаг 2. Обновление платформы «1С:Предприятие»
Если режим совместимости критически важно оставить отключенным (или конфигурация работает на управляемых формах), проблема кроется в платформенном баге.
8.3.11.2924), выполните обновление на актуальный стабильный релиз платформы (например, из последних сборок веток 8.3.20, 8.3.22 или выше в зависимости от требований вашей конфигурации).Шаг 3. Ревизия доработанных элементов формы
Если в документ вносились изменения (добавлялись новые реквизиты, списки или элементы управления):
Шаг 4. Очистка серверного и клиентского кэша
Иногда искаженные файлы кэша метаданных на стороне клиента мешают правильному сопоставлению типов ошибок. Очистите кэш у пользователя, у которого воспроизводится падение:
%userprofile%\AppData\Local\1C\1Cv8 и %userprofile%\AppData\Roaming\1C\1Cv8 (предварительно завершив работу всех сеансов 1С).Шаг 5. Борьба с зависшими сеансами на сервере
Регулярно проводите профилактику серверного окружения:
Применяя данные шаги на практике, мы сможем гарантировать стабильную многопользовательскую работу в системе 1С без раздражающих вылетов и потерь несохраненных данных.