время жизни сеанса http сервис 1с в чем
Заметки из Зазеркалья
Реализовано в версии 8.3.9.1818.
В версии 8.3.9 мы выполнили значительное количество задач по оптимизации разных механизмов платформы. Здесь хочется рассказать об одной из них. Это повышение производительности веб-сервисов.
Переиспользование сеансов
Недостаточная производительность веб-сервисов объяснялась тем, что каждый вызов веб-сервиса имел значительные накладные расходы на создание и завершение сеанса. Причём при создании каждый раз выполнялся обработчик УстановкаПараметровСеанса(), который в типовой конфигурации может быть довольно «тяжёлым».
Кроме этого существовал и функциональный недостаток. Веб-сервисы не обладали состоянием. Это не позволяло реализовывать логику, использующую сохранение состояния между вызовами веб-сервиса.
В версии 8.3.9 мы доработали механизм веб-сервисов (SOAP-сервисы, HTTP-сервисы, сервисы OData). В результате их производительность увеличилась примерно в 10 раз.
Мы проводили тесты на типовой конфигурации Бухгалтерия предприятия. В неё мы добавили HTTP-сервисы, выполняющие выборку из справочника Контрагенты. Тест заключался в том, что клиент выполнял последовательно 100 обращений к сервису. В старом режиме работы для этого потребовалось 29,9 с. В новых режимах работы в среднем 3 с.
Этих результатов удалось достичь за счёт того, что мы реализовали две различные стратегии, обеспечивающие переиспользование сеансов:
При автоматическом переиспользовании сеансов клиент не имеет возможности влиять на количество сеансов и время их жизни. Ему просто автоматически выделяется сеанс из существующего пула сеансов. Такая стратегия подходит для высоконагруженных публичных сервисов, к которым обращаются клиенты, выполняющие шаблонные операции, и обладающие унифицированными привилегиями.
Например, это может быть автоматизация торговой деятельности удаленных торговых точек, предусматривающая периоды пиковой нагрузки на сервер. Для обработки будет выделено нужное количество сеансов. Они будут завершены по мере падения нагрузки.
Другой пример это получение/помещение файлов в конфигурации Документооборот посредством http-сервисов. Для таких операций можно использовать одного и того же специального пользователя.
Стратегия ручного управления сеансами подразумевает, что клиент самостоятельно управляет количеством сеансов и временем их жизни. Эта стратегия лучше подходит для высокоинтегрированных систем в рамках одной организации. Вы можете реализовать собственный алгоритм, который будет управлять временем жизни сеансов и их количеством.
Средства управления
Необходимость использования одной или другой стратегии вы можете определить в дереве объектов конфигурации, и, при необходимости, переопределить в файле публикации default.vrd. В дереве объектов конфигурации мы добавили два новых свойства объектам Web-сервис и HTTP-сервис:
В файле default.vrd для элементов, описывающих SOAP-сервисы, HTTP-сервисы и сервисы OData, мы ввели несколько новых атрибутов:
Например, файл default.vrd может выглядеть так:
Файл default.vrd имеет больший приоритет, чем конфигурация. При публикации конфигурации атрибуты reuseSessions и sessionMaxAge заполняются из соответствующих свойств объектов конфигурации Web-сервис и HTTP-сервис. Но при необходимости вы можете изменить эти значения прямо в файле, и тогда платформа будет использовать их, а не значения из конфигурации.
Автоматическое переиспользование сеансов
Сеансы в пуле хранятся в разрезе типа сервиса, наименования сервиса, пользователя/пароля, значений разделителей и безопасного режима. Причём в пуле может быть несколько сеансов с одинаковыми значениями перечисленных реквизитов.
При вызове платформа проверяет, есть ли простаивающий сеанс с подходящим сочетанием этих реквизитов. Если такой сеанс есть, то он выделяется для обработки вызова. Если такого сеанса нет, то создается новый сеанс и выделяется для обработки.
Сеанс автоматически завершается по истечении периода бездействия (ВремяЖизниСеанса).
Если достигнуто максимальное количество сеансов (poolSize), то вызов ждет указное время (poolTimeout). Если за это время подходящий сеанс не освободился, то возвращается ошибка со статусом 406 Not Acceptable.
Настройки автоматического пула сеансов действуют в рамках публикации. Это значит, что если у вас есть несколько публикаций для одной и той же информационной базы, то при вызове действуют те параметры, которые указаны в публикации, к которой обращается текущий вызов. Таким образом, если в одной публикации для сервиса указан лимит в 3 сеанса, а в другой публикации 5, то общее количество сеансов, которое может быть создано для вашей информационной базы равняется сумме этих значений 8.
При выборе размера пула следует учитывать все разрезы, в которых хранятся сеансы в пуле. Мы рекомендуем устанавливать размер пула немного больше, чем количество возможных вариантов. Это позволит вам избежать ситуации, когда пул заполнен сеансами, и вызов с новой комбинацией разделителей/пользователей обработан быть не может.
Эта стратегия не подходит для сценариев, в которых нужно использовать сохранённое состояние сеанса на сервере. Потому что нет никакой гарантии, что при следующем вызове клиент будет подключен к тому же самому сеансу. Как мы говорили в начале, в пуле может быть несколько сеансов с одинаковыми значениями ключевых реквизитов.
Управление сеансами
Инициатором создания и завершение сеанса является клиент сервиса. Чтобы создать постоянный сеанс клиент должен передать заголовок IBSession в http – запросе. Этот заголовок вы устанавливаете вручную. Значением этого заголовка должна быть директива start.
После получения такого заголовка на сервере стартует сеанс информационной базы, происходит аутентификация, установка разделителей и вызывается обработчик УстановкаПараметровСеанса().
Если клиент затребовал создание сеанса, а сервер не может это сделать, генерируется сообщение об ошибке 406 Not Acceptable.
Если всё хорошо и сеанс создан, платформа помещает в http-ответ директиву установки куки IBSession с идентификатором созданного сеанса.
Для подключения ранее созданного сеанса, вам необходимо указать куки IBSession с идентификатором сеанса.
Для завершения сеанса вам нужно использовать заголовок IBSession http-запроса. Его нужно установить в директиву finish.
Получив сообщение с таким заголовком, сервер отрабатывает вызов, и закрывает сеанс.
Эта стратегия позволяет вам реализовать сценарии, в которых используется состояние сеанса, сохранённое на сервере. Потому что вы имеете уникальный идентификатор сеанса. Единственное, о чём нужно помнить, что завершение сеанса может происходить не только по вашей «команде», но и автоматически. В том случае, когда превышен период бездействия сеанса (ВремяЖизниСеанса). Поэтому вы, как клиент сервиса, должны быть готовы к тому, что сеансовые данные могут быть сброшены, если сеанс завершен.
Веб-сервисы в расширениях
Если объекты конфигурации Web-сервис или HTTP-сервис располагается в расширении конфигурации, то возможность редактировать свойства ПовторноеИспользованиеСеансов и ВремяЖизниСеанса у вас отсутствует. Поэтому, если вы хотите включить автоматическое или ручное переиспользование сеансов, вам нужно использовать для этого файл default.vrd.
В дальнейшем мы будем рассматривать возможность поддержки этих свойств в расширениях.
Завершение сеанса активных пользователей веб-клиента
В параметрах время засыпания сеанса и время удаления неиспользуемого спящего сеанса в разделе Администрирование/ Параметры информационной базы можно установить интервал времени, по истечении которого неактивный сеанс переводится в спящий режим и интервал времени, по истечении которого спящий сеанс завершается. Я предлагаю такие параметры параметры – 300 и 10 соответственно.
Если пользователь покидает базу (завершил сеанс) – его сеансовые данные удаляются. В режиме клиент сервер, сеансы хранятся на кластере серверов, за это отвечает менеджер кластера, именно для этого существует сервис сеансовых данных. Чтобы ускорить работу, данные сеансов кешируются в рабочих процессах и в толстых клиентах. При перезапуске кластера серверов данные сеансов будут сохранены. В том случае если активный пользователь не выполнил ни одного обращения к кластеру в течение 20-ти минут и сеанс не назначен соединению, то сеанс удаляется вместе с его данными. Для поддержания сеанса тонкий клиент и веб-клиент обеспечивают обращение к кластеру не реже 1 раза в 10 минут.
Однако. из-за нештатного завершения, сеанс может блокироваться и не переходить в спящий режим, и следовательно, завершиться автоматически не может и нужно их удалить через консоль сервера предприятия
Однако в файловом режиме, для снятия заблокированного сеанса веб-клиента не достаточно перезагружать web-сервер apache. Это обычно не помогает. Можно попытаться перезагружать ПК, где запущен браузер, но это тоже иногда не помогает. Лучше всего помогает запустить конфигуратор от имен администратора и снова опубликовать ИБ в разделе Администрирование/Публикация на веб- сервере.
HTTP-сервис в 1С: создание, публикация и отладка
В платформе версии 8.3.5 появилась возможность создавать HTTP-сервисы. Как и «старые» SOAP web-сервисы, HTTP-сервис позволяет получать/изменять данные, но при этом, как утверждает компания 1С, HTTP-сервисы потенциально позволяют упростить создание клиентских приложений, уменьшить объем передаваемых данных и вычислительную нагрузку, все это особенно для мобильных устройств.
В этой статья я постараюсь рассказать о том, как создавать, отлаживать и использовать HTTP-сервисы в 1С.
Начнем с того, что для создания HTTP-сервиса нам необходим веб-сервер, например Apache 2.2 (начиная с версии 8.3.8 и Apache 2.4 подойдет). Описывать установку веб-сервера думаю нет необходимости.
Создание HTTP-сервиса
Итак, создаем новый HTTP-сервис:
Корневой URL — важный параметр, входит в адрес по которому сервис будет доступен после публикации.
В соответствующем разделе создаем новый шаблон URL и метод:
У шаблона URL есть единственное свойство — шаблон. Этим свойством можно задать путь по которому будет происходить обращение к HTTP-сервису. В шаблоне можно использовать параметризованные сегменты, как на рисунке ниже (об их использовании ниже).
У метода есть свойство HTTP-метод, которое можно указать выбрав одно из следующих значений: GET, POST, PUT, DELETE, PATCH, MERGE, CONNECT, OPTIONS, TRACE, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK или Любой.
При обращении к HTTP-сервису, платформа пытается сопоставить адрес, по которому произошло обращение с одним из имеющихся шаблонов и методов. Если сопоставить удалось, то будет выполнен обработчик метода, если же сопоставить не удалось, то будет возвращен код ответа 404.
Перейдем к примеру обработчика метода, в нем я возвращаю содержимое переменной «Запрос», которая передается в обработчик:
Публикация и проверка HTTP-сервиса
Наш HTTP-сервис готов к публикации, в этом нет ничего сложного (вероятно потребуется запустить конфигуратор от имени администратора):
После публикации я могу обратиться к сервису вот по такому адресу: http://localhost/HTTPTest/hs/Obmen/test-parametr/Test/GetInfo?param=value, где:
Параметры URL, параметры запроса и заголовки представлены в виде фиксированных структур.
Вероятнее всего, при обращение к HTTP-сервису нужно будет авторизоваться (если в базе есть хоть один пользователь), есть несколько способов решения этой проблемы.
Первый — изменить файл default.vrd, который находится в каталоге публикации. В этом файле нужно дополнить строку подключения к базе, например, было:
ib=»File=»C:\Base\TEST»;»,
ib=»File=»C:\Base\TEST»;Usr=Логин;Pwd=Пароль».
В этом случае любые обращения к HTTP-сервису не будут требовать логина и пароля.
Во-вторых, можно указывать логин и пароль при подключении к HTTP-сервису:
Ваш браузер устарел, пожалуйста обновите ваш браузер пройдя по ссылке www.microsoft.com/download
Универсальный HTTP-сервис на платформе 1С, аля HTTP-сервер с примером
В комментариях к статье 1C + Python + Django Rest Framework + Vue.js. Опыт несложной full-stack разработки я оставил комментарий и предложил другой путь решения подобных задач. Завязалась дискуссия в ходе которой я предложил свой подход, который успешно опробован на наших клиентах к решению аналогичной задачи (личный кабинет для техподдержки).
Исходная задача
В организации есть рабочая информационная база 1С (она же учетная система). Необходимо создать личный кабинет для пользователей с возможностью web-доступа. Причем пользователи должны полноценно работать в любом браузере, интерфейс желательно иметь адаптивный (меняет дизайн страницы в зависимости от поведения пользователя, платформы, размера экрана и ориентации устройства: компьютера, смартфона, планшета). Личный кабинет должен быть достаточно легко модифицируемым и расширяемым.
Задач такого круга масса: личный кабинет покупателя для заказа товаров онлайн, внесение показаний счетчиков в сфере ЖКХ, службы доставки товаров, техподдержка и прием заявок клиентов и т.д.
Варианты решений
Первый вариант. Классический. Разделить личный кабинет и информационную базу 1С. Это самый древний способ, который к нам пришел еще с бородатых времен 1С версии 7.7. Личный кабинет при этом делается на каком-нибудь веб-движке и при необходимости какой-нибудь веб-ориентированной СУБД. Например, PHP + MySQL или Django Rest Framework + Vue.js + MariaDB. При этом время от времени происходит обмен данными между веб-частью и центральной ИБ на 1С и происходит синхронизация данных.
Несмотря на то, что это один из первых способов, который появился очень давно, его успешно продолжают использовать и по сей день.
С развитием платформы и выходом версии 8.2 появился еще один способ.
Вариант два. Использование стандартного web-клиента 1С. Зачем делить систему на части, если можно дать пользователям доступ к рабочей базе, разграничить все права и пользователь сможет видеть только то, что ему нужно?
Вариант три. Использование HTTP-сервисов 1C. С выходом 8.3 в платформу были добавлены новые механизмы: сначала web-сервисы для интеграции с другими информационными системами, а потом и HTTP-сервисы, предназначеные для обработки HTTP-запросов, которые сначала поступают на веб-сервер, который передает на обработку эти запросы 1С, а уже 1С обрабатывает эти запросы и возвращает результат так же по протоколу HTTP, браузер видит ответ и отображает пользователю результат. При этом мы можем возвращать HTTP-запросам клиентов АБСОЛЮТНО любые данные: картинки, HTTP-страницы, JSON-данные, обычный текст и т.п.
На ИСе много примеров использования HTTP-сервисов среди которых:
Но все они не универсальные и заточены под одну конкретную задачу или решение какой-то одной проблемы. Я бы хотел остановится на использовании HTTP-сервисов немного в другом контексте.
Вариант четыре. Он же гибридный вариант три. Универсальный HTTP-сервис.
Это уже мой подход к этому вопросу. Я долго думал, на тему как сделать так, чтобы HTTP-сервис не нужно было постоянно бы изменять в конфигураторе (хотя это спорно, так как сейчас все идет к расширениям и этот функционал можно реализовать через расширение конфигурации) и реализовать что-то универсальное. И мысли примерно следующие: по факту HTTP-сервис всегда работает по алгоритму: пришел какой-то запрос вида http://site.ru/hs/lk/index.html необходимо понять, что от нас хотят, покопаться в 1С, возможно сделать какой-то запрос или еще что-то и отдать соответствующий ответ. Т.е. схема работы HTTP-сервиса примерно такая:
Т.е. если мы в браузере открыли страничку по адресу: http://site.ru/hs/lk/index.html которую обработал HTTP-сервис и вернул нам:
То автоматически браузером будет выполнен второй запрос по адресу: http://site.ru/hs/lk/images/1.png и в браузер будет подставлена картинка, которая получена вторым запросом.
Т.е. количество запросов к HTTP-сервису будет 2, а показана всего одна страничка, но на ней будет картинка. Если ссылок в документе будет несколько, то каждый раз браузер будет обращаться к HTTP-сервису и просить у него то, чего ему не хватает. Круто да?
Что это дает нам? А это позволяет нам сделать следующее: если мы научимся хранить данные, которые мы хотим отдавать пользователям, присвоим им адреса, по которым можно будет их найти, научимся обрабатывать не найденные страницы и HTTP-сервис будем использовать как низкоуровневую прослойку между этими данными и пользователями, то мы получим универсальный механизм. Мы получаем образно говоря HTTP-сервер на платформе 1С.
Отличие понятий сеанс и соединение в «1С:Предприятие 8»
Отличие понятий сеанс и соединение в «1С:Предприятие 8»
В чем отличия между сеансом и соединением? Этот, на первый взгляд, простой вопрос на экзамене 1С:Эксперт многих ставит в тупик. Несмотря на немалый опыт программирования, сформулировать четкий и правильный ответ сможет далеко не каждый специалист.
В данной статье проведем детальный разбор этого вопроса. Для начала рассмотрим по отдельности понятия сеанс и соединение в 1С:Предприятие. Отметим, что информация актуальна для версий платформы 8.2.x и 8.3.x.
Сеанс 1С
Обратимся к руководству администратора. В нем понятие сеанса определено следующим образом:
Сеанс определяет активного пользователя информационной базы и поток управления этого пользователя.
Можно сказать, что кластер серверов не видит пользователей, вместо них он видит сеансы и сеансовые данные. В консоли управления кластером в принципе отсутствует раздел «Пользователи», под пользователями кластер понимает сеансы.
Это подтверждает визуальное представление пункта «Сеансы» – иконка отображается в виде пользователей.
Следует уточнить, что под активным пользователем не обязательно понимается клиентское соединение, это также может быть:
Сеансовые данные
Рассмотрим понятие сеансовые данные. Сеанс содержит в себе некоторую информацию, такую как:
Такая информация называется сеансовыми данными. Причем для каждого активного пользователя сеансовые данные свои, и актуальны они только на время его работы. Если пользователь покидает базу (завершил сеанс) – его сеансовые данные удаляются.
Данные сеансов хранятся на кластере серверов, за это отвечает менеджер кластера, именно для этого существует сервис сеансовых данных. Чтобы ускорить работу, данные сеансов кешируются в рабочих процессах и в толстых клиентах.
При перезапуске кластера серверов данные сеансов будут сохранены. В том случае если активный пользователь не выполнил ни одного обращения к кластеру в течение 20-ти минут и сеанс не назначен соединению, то сеанс удаляется вместе с его данными.
Для поддержания сеанса тонкий клиент и веб-клиент обеспечивают обращение к кластеру не реже 1 раза в 10 минут.
Соединение 1С
Теперь разберемся с понятием соединение. Вновь обратимся к руководству администратора:
Соединение является средством доступа сеансов к кластеру серверов «1С:Предприятие», содержит ограниченное множество данных соединения, не отождествляется с активным пользователем.
Другими словами, с помощью соединения сеанс получает доступ к кластеру. При этом количество соединений ограничено, и как только таковое становится не нужным сеансу, оно возвращается в пул соединений.
В случае если сеанс не обращается к кластеру, то есть пользователь бездействует, ему не будет назначено соединение. Таким образом, сеанс может существовать без соединения.
Нужно отметить, что сеансовые данные хранятся на сервере, поэтому если разрыв соединения длится менее 20 минут, то на сеансе это не отразится, ведь соединение – всего лишь средство доступа.
Например, если случайно выдернуть сетевой кабель, пользователь не получит сообщение об ошибке, если успеть подключить кабель в течение 20 минут. В этом случае сеансу будет назначено новое соединение, и он продолжит работу. Пользователь даже не узнает о проблеме, за исключением, возможно, легкого «подвисания».
Также соединения используются для взаимодействия процессов кластера, то есть рабочие процессы (rphost) общаются с менеджером кластера (процесс rmngr) при помощи соединений, а не с помощью сеансов.
Отличия соединения от сеансов
Для того чтобы описать основное отличие данных понятий, приведем аналогию.
Допустим, что сеанс – это пассажир, а соединение – такси. Когда пассажиру необходимо добраться домой (сеансу нужно подключится к серверу), он вызывает такси (сеансу назначается соединение из пула соединений).
Если, добравшись домой, пассажир захочет снова поехать на работу, а такси уже уехало (после подключения случился разрыв соединения), то пассажир вызывает новое такси и едет по своим делам (сеансу назначается новое соединение).
В данной аналогии наглядно представлено, что сеанс и соединение далеко не одно и тоже, и сеанс может довольно легко перенести разрыв соединения.
PDF-версия статьи для участников группы ВКонтакте
Если Вы еще не вступили в группу – сделайте это сейчас и в блоке ниже (на этой странице) появятся ссылка на скачивание материалов.
Содержание курса и форма заказа: https://курсы-по-1с.рф/1c-v8/optimization/
35 учебных часов, подготовка к 1С:Эксперт, правильная настройка серверной части, оптимизация кода, мониторинг загруженности оборудования и прочие взрослые вещи.
Комментарии / обсуждение (11):
Добрый день.
В управляемом приложении (8.3.16.1224) постоянно есть сеансы за прошлый и более ранние дни. И это несмотря на то, что в параметрах ИБ выставлены значения засыпания пассивного сеанса в 1200 с., а время завершения спящего сеанса 14400 с. В консоли кластера такие сеансы видны как не спящие.
В руководстве администратора есть такая фраза:
“Если компьютер клиента не находится в режиме энергосбережения, и клиентское приложение бездействует (не выполняет никаких действий пользователя), то оно периодически вызывает сервер «1С:Предприятия» с интервалом 5-10 минут для поддержания активности сеанса. Поэтому не рекомендуется устанавливать время засыпания сеанса меньше 10 минут.”
Не является ли это противоречием? Получается, если я настрою время засыпания больше этих “5-10 минут” то сеанс не заснет фактически никогда (что, как мне кажется, и происходит), т.к. будет происходить периодический вызов сервера? Можно ли каким-либо другим образом отключать неактивных пользователей?
Добрый день, Михал!
Спящие сеансы – это сеансы которые завершены пользователем, но сервер 1С их не закрывает (что-бы не создавать повторно). У вас видимо другой случай: клиентские сеансы запущены на рабочих местах пользователей и именно про это пишут в руководстве администратора. Если-бы у ваших клиентов 1С сверх того были открыты динамические списки – они-бы периодически посылали запросы.
Я просмотрел Ваш курс, прочитал в документации, и в некоторых других источниках… Всё равно не до конца понимаю некоторые моменты:
1. Если соединение это средство доступа, тогда почему при удалении соединения из консоли управления кластером, сеанс также удаляется?
2. Соединения между чем и кем создаются? Я всегда думал что между пользователем и рабочим процессом. А Вы пишете “Также соединения используются для взаимодействия процессов кластера, то есть рабочие процессы (rphost) общаются с менеджером кластера (процесс rmngr) при помощи соединений”. Или может быть соединения эти устанавливаются между несколькими источниками?
3. соединение физически это “канал связи” между чем-то и чем-то или, это просто “записи некой таблицы внутри оперативной памяти сервера приложения” с громким названием “Соединения”? Я провёл тест, вынул сетевой провод из сервера, а затем вставил. По логике, соединение (канал связи) должно было тут же оборваться, а оно не оборвалось…
1. При удалении соединения сеанс остается, ему назначается новое соединение.
2. Как я и описал, это так же средство общения между процессами. Не понятно зачем устанавливать соединения между несколькими источниками. У вас есть только 2 процессы которые в момент времени могут между собой общаться.
3. Наверняка это знают только разработчики платформы, в документации такие тонкости не описаны.
1. Теоретически это так и должно быть. Но практика показывает, что если удалить соединение, тогда сеанс тоже удаляется, при этом нового соединения ему автоматически не назначается. Кстати говоря, я ещё раз пересмотрел раздел продвинутого курса Евгения Гилёва, в котором он более кратко описывал работу в клиент-серверном режиме работы платформы, и он тоже показал и заострил внимание на том, если удалить соединение, тогда сеанс тоже удаляется. Но вот почему так происходит, тоже не объяснил. ((
2. Что значит “так же средство общения между процессами”. Разве установив соединение между двумя объектами, система сможет общаться с третьим объектом?
PS: например, я позвонил по телефону своей маме (для этого установил “соединение”), смогу ли я в этом случае одновременно пообщаться с братом, при условии что он находится не в том же месте, где мама?
3. А какие тут тонкости? Я просто хочу понять, что из себя представляет понятие “соединение”.
Определение “Соединение – это средство доступа сеанса, к кластеру серверов” звучит очень размыто. Появляется дополнительный вопрос “что такое СРЕДСТВО ДОСТУПА”? Толи это запись некой таблицы, толи реальный канал связи…
4. А если допустим это запись таблицы, тогда какой в ней смысл, почему не заменить две сущности “сеанс + сединеие” в какое-то одно название. Чтобы небыло двух этих объектов, а был какой-то им аналогичный один объект.
5. А ещё Вы упомянули про некий ПУЛ СОЕДИНЕНИЙ. Что когда соединение больше не нужно, оно возвращается в пул соединений. Получается, что количество соединений ограничено, и находятся все они в этом пуле, и получается, что сначала соединение может быть назначено одному сеансу, затем по ненужности вернуться в пул, а через некоторое время назначиться другому сеансу?
1. Я говорю не про теорию, у меня на практике удаление соединения не приводит к удалению сеанса. Сеансу просто назначается другое соединение.
2. Причем тут 3 объекта. rphost общается с rmngr через соединение, эти соединения мы не видим в консоли.
3-4. Нельзя объединять сеанс и соединение, как минимум потому, что у соединения нет сеансовых данных. Как реализовано соединение в платформе на физическом уровне я не знаю, я не разработчик платформы, да если честно мне это все равно. На настройку кластера и оптимизацию это знание никак не повлияет. Если разработчики сделали 2 сущности, а не одну значит на то были причины, и мы можем либо тратить свое время на догадки почему они сделали именно так, либо просто принять это как есть и разобраться в том как это сейчас работает.
5. Да, все верно.
ОГО, ЧУДЕСА, в тонком клиенте и правда нету удаления сеанса, и назначается новое соединение сеансу.
У нас то просто УПП 1.3. Я все эксперименты из вашего курса и не только как правило делал на ней. А там основной режим работы: толстый клиент, обычное приложение. В обычном приложении почему-то при малейшем обрыве сети, соединение рвётся, сеанс удаляется. Даже если не надолго из сервера вытащить сетевой провод.
Да, толстый клиент работает так. Я и забыл уже что кто-то на толстом клиенте работает 🙂