Пролог
Возникла задача: на типовом решении интерактивно запускать длительную обработку так, чтобы было видно как идет процесс (индикатор %). При этом большая часть обработки происходит на сервере, а использование фонового задания для этих целей оказалось не применимо. Единственным приемлемым решением было применить регулярые вызовы сервера, во время каждого из которых обрабатывалась очередная порция, а на клиенте двигался индикатор %. Объем временных служебных данных во время обработи на стороне сервера оказался большой, поэтому гонять его туда-сюда при контекстных вызовах слишком накладно. Как было бы замечательно поместить их в глоальную переменную на сервере и использовать вызовы безконтекста формы. Как известно, глобальные переменные в контексте сервера невозможны, а использование стандартных параметров сеанса очень медленно, использование временного хранилища еще медленней. Но если нельзя, а очень хочется, то получается вот такое:
Описание алгоритма
Все устроено так, как если бы была глобальная переменная (например, глОбщиеЗначения) содержащая структуру, и в эту структуру можно сложить что угодно (как, например, слона в холодильник :)) ) и при этом максимально быстро. Естественно, на клиенте и на сервере эти переменные разные и нужно их как-то синхронизировать. Все решается путем применения сохраняемых на время сеанса результатов функций из общих модулей. Но есть одно НО: эти значения внезапно смертны. Вот цитата из справки:
Сохраненные значения могут быть удалены:
- после долгого неиспользования (более 5 минут);
- при нехватке оперативной памяти в рабочем процессе сервера;
- при перезапуске рабочего процесса;
- при переключении клиента на другой рабочий процесс.
Время в первом пункте может варьироваться от релиза к релизу, но принцип сохраняется и подтверждается экспериментами. Поэтому для обеспечения их живучести пришлось пойти на сохранение этих структур в одном из обычных параметров сеанса с типом хранилище значения. Сохранение происходит регулярно, но не слишком часто, чтобы не сбивать производительность. Если структуры из сеансовых данных "помрут", они будут воссозданы заново из сохраненных в обычном параметре сеанса.
При обрашении БПС_Общие.ПолучитьПараметрСеанса (ИмяПараметра) на клиенте проверяется клиентская структура, если нет нашли - проверяется серверная структура (серверный вызов), если не нашли - проверяется вся коллекция стандартных параметров сеанса (т. е. параметры сеанса могут быть скопированы на клиента и в дальнейшем доступны быстро, естественно, помним про ограничения по типам), если не нашли - проверяется сохраненная ранее в служебном параметре сеанса структура, если не нашли - пытаемся вызвать функции получения значений по-умолчанию типовых конфигураций, если таковые имеются. Полученные по цепочке значения сохраняются на сервере и возвращаются на клиента. При обрашении БПС_Общие.ПолучитьПараметрСеанса (ИмяПараметра) на сервере все происходит по той же цепочке, только начинается с сервера.
При обрашении БПС_Общие.УстановитьПараметрСеанса (ИмяПараметра, ЗначениеПараметра, ОбновлятьСервер) на клиенте происходит установка нового значения параметра. ОбновлятьСервер указывает сразу установить значение и на стороне сервера и сохранить структуру в служебный обычный параметр сеанса. При обрашении БПС_Общие.УстановитьПараметрСеанса (ИмяПараметра, ЗначениеПараметра, ОбновлятьСервер) на сервере выполняется все так же. ОбновлятьСервер указывает сразу сохранить структуру в служебный обычный параметр сеанса.
Такое временное хранение данных может "отъесть" значительный кусок памяти на сервере, поэтому "после того как" желательно прибрать мусор. Для этого используем вызовы БПС_Общие.УдалитьПараметрСеанса (ИмяПараметра, ОбновлятьСервер) соответственно на клиенте / на сервере.
Особенности
Реализовано в виде расширения с назначением: Адаптация. Из расширяемой конфигурации заимствованы только процедура модуля приложения ПриНачалеРаботыСистемы и процедура модуля сеанса УстановкаПараметровСеанса. Если процедуры ПриНачалеРаботыСистемы нет в расширяемой конфигурации, ошибки не будет, но не будет работать регулярное сохранение в стандартный параметр сеанса при бездействии (при обращении проверка необходимости сохранения продолжит работать). Все остальное только добавлено и не пересекается с типовыми объектами/именами.
До платформы 8.3.14 в расширение нельзя было добавить свои параметры сеанса, поэтому реализовано два расширения:
- БыстрыеПараметрыСеанса.8.3.14.cfe - для платформы и режима совместимости 8.3.14 и выше
- БыстрыеПараметрыСеанса.8.3.13.cfe - для платформы и режима совместимости с 8.3.9 по 8.3.13
Расширение 8.3.14 следует использовать только если и платформа и режим совместимости расширяемой конфигурации 8.3.14 и выше. В противном случае следует использовать расширение 8.3.13. В нем среди стандартных параметров сеанса ищется подходящий с типом ХранилищеЗначения и содержащий структуру. Обычно хоть один такой имеется если в конфигурацию внедрены стандартные библиотеки.
Если наслаиваются несколько расширений, то это желательно поставить первым в списке (ближе к расширяемой конфигурации).
Если заимствовать содержимое расширения и внедрить в конфигурацию непосредственно, то можно вынести функции и процедуры в глобальный контекст, естественно, разделяя клиент и сервер.
Эпилог
Просьба не выкладывать скачанные файли или код из них на варезных форумах, 1sm - не такая уж великая цена. А если не утерпели, то хотя бы проставляйте ссылку на первоисточник.
Вступайте в нашу телеграмм-группу Инфостарт
