Проблема «зависших» сессий и блокировок объектов в веб-клиенте 1С — это классическая ситуация, с которой сталкиваются системные администраторы и разработчики при публикации баз через веб-серверы (Apache или IIS). Основная причина кроется в том, что при простом закрытии вкладки браузера или самого окна программы, сервер не получает мгновенного сигнала о завершении работы пользователя. В результате сессия остается активной в кластере 1С, а открытый документ удерживает объектную блокировку, не позволяя другим (или тому же пользователю при повторном входе) редактировать данные.
В этой статье мы подробно проанализируем ситуацию и разберем несколько эффективных методов решения этой проблемы: от изменения логики работы в коде до тонкой настройки веб-сервера и параметров кластера 1С:Предприятие.
Рассмотрим наиболее надежный программный способ, предложенный опытными разработчиками. Суть его заключается в отказе от прямого редактирования документа через его основную форму. Вместо этого мы создаем специальную обработку (объект Обработка), форма которой визуально повторяет форму документа.
Давайте разберем, почему это работает. Когда пользователь открывает основную форму документа в режиме редактирования, платформа 1С автоматически устанавливает «объектную блокировку» на этот документ. Пока форма открыта, никто другой не может записать этот объект. Если браузер закрывается некорректно, форма «зависает» на сервере вместе с этой блокировкой.
Если же мы используем обработку, проанализируем последовательность действий:
Посмотрим на пример кода, который может быть вызван при нажатии кнопки в такой обработке:
&НаСервере
Процедура ЗаписатьЗаявкуНаСервере()
// Создаем объект документа программно
НоваяЗаявка = Документы.ЗаявкаОтОтдела.СоздатьДокумент();
// Заполняем данные из реквизитов формы обработки
ЗаполнитьЗначенияСвойств(НоваяЗаявка, Объект);
// Устанавливаем дополнительные параметры
НоваяЗаявка.Дата = ТекущаяДатаСеанса();
НоваяЗаявка.Автор = Пользователи.ТекущийПользователь();
Попытка
// Блокировка и запись происходят в краткий миг выполнения этой процедуры
НоваяЗаявка.Записать(РежимЗаписиДокумента.Проведение);
Сообщить("Заявка успешно создана!");
Исключение
Сообщить("Ошибка при сохранении: " + ОписаниеОшибки());
КонецПопытки;
КонецПроцедуры
При таком подходе документ блокируется только на доли секунды в момент выполнения метода Записать(). Если пользователь закроет браузер на середине заполнения, никакой блокировки в базе не останется, и другие участники процесса смогут беспрепятственно работать с системой.
Выясним причину, по которой веб-сервер долго держит сессию. При публикации базы создается файл default.vrd. В нем содержатся критически важные параметры, управляющие соединением. Проанализируем параметры, которые помогут нам ускорить освобождение ресурсов.
Найдите в файле default.vrd (обычно он находится в каталоге публикации на Apache или IIS) секцию настроек и обратите внимание на следующие атрибуты:
Пример настройки в default.vrd:
<point xmlns="http://v8.1c.ru/8.2/virtual-resource-system"
base="/MyBase"
ib="Srvr=Server1C;Ref=MyBase;">
<ws>
<sessionMaxAge>300</sessionMaxAge>
</ws>
</point>
Начиная с версии платформы 8.3.15, механизм управления сеансами был значительно доработан. Платформа научилась разделять сеансы на активные и спящие. Рассмотрим, как это использовать для борьбы с блокировками.
Когда пользователь закрывает вкладку, сеанс не завершается мгновенно, а переходит в состояние «Спящий». В консоли администрирования кластера 1С (или через функции программного администрирования) можно настроить параметр «Время завершения спящего сеанса». По умолчанию он может составлять многие часы. Для эффективной работы в веб-клиенте рекомендуем установить это значение в пределах 5–15 минут.
Как только сеанс из «спящего» окончательно удаляется платформой, все объектные блокировки, которые он удерживал, снимаются автоматически. Это избавляет системного администратора от необходимости вручную «выбивать» пользователей из базы.
Проанализируем взаимодействие веб-сервера Apache с клиентом. Если вы используете Apache, важную роль играет директива KeepAliveTimeout. Она определяет, сколько секунд сервер будет ждать нового запроса по текущему TCP-соединению, прежде чем закрыть его.
Если это значение слишком велико (например, стандартные настройки некоторых сборок), Apache удерживает соединение, и платформа 1С «считает», что клиент всё еще на связи. Рекомендуется установить значение KeepAliveTimeout в диапазоне от 5 до 15. Это позволит серверу быстрее понять, что соединение разорвано, и инициировать процедуру перевода сеанса 1С в спящий режим.
Если использование обработок (Метод 1) невозможно из-за сложности переработки конфигурации, разберем способ ручного управления блокировками. Мы можем использовать метод ЗаблокироватьДанныеДляРедактирования().
В этом случае мы можем реализовать механизм «мягкой» блокировки. Например, при открытии формы мы проверяем, не заблокирован ли объект. Если он заблокирован тем же самым пользователем (предыдущий «зависший» сеанс), мы можем программно разрешить редактирование, «перехватив» блокировку или уведомив пользователя о возможности принудительного снятия старой блокировки.
Посмотрим, как можно проверить наличие блокировки:
&НаСервере
Функция ПроверитьИУстановитьБлокировку(СсылкаНаДокумент)
Попытка
// Пытаемся заблокировать объект программно
СсылкаНаДокумент.Заблокировать();
Возврат Истина;
Исключение
// Если объект уже заблокирован в другом сеансе
Возврат Ложь;
КонецПопытки;
КонецФункции
Важный нюанс: современные браузеры (Chrome, Firefox) из соображений безопасности блокируют синхронные запросы при событии onbeforeunload (закрытие вкладки). Это означает, что стандартная попытка 1С отправить сигнал «Logout» при закрытии крестиком часто игнорируется браузером. Именно поэтому настройки на стороне сервера (default.vrd и параметры кластера) являются приоритетными по сравнению с попытками «поймать» закрытие окна в коде формы.
Подводя итог, проанализируем лучший алгоритм действий: в первую очередь обновите платформу до актуальной версии (не ниже 8.3.15), настройте время завершения спящих сеансов в консоли кластера на минимально разумное (10-15 минут) и, по возможности, переведите критически важные узлы ввода данных на использование обработок вместо прямого редактирования объектов документов. Это обеспечит максимальную стабильность системы и избавит пользователей от раздражающих сообщений о блокировке данных.