Подробно опишите механизм управления сеансом в Tomcat:
1. Операция сеанса во время процесса запроса:
Краткое описание: Во время процесса запроса сначала проанализируйте информацию SessionID в запросе, а затем сохраните SessionID в списке параметров запроса. Затем, когда вы получите сеанс из запроса, если SessionID существует, вы получите сеанс из пула сеанса на основе идентификатора. Если SessionID не существует или сеанс не удается, создайте новый сеанс и поместите информацию сеанса в пул сеанса для следующего использования.
(1) Диаграмма сроков срока процесса анализа сеанса:
Обзор: Во -первых, пользователь отправляет HTTP -запрос, чтобы передать его в HTTP11Processor, а затем передает его Coyoteadapter через HTTP11Processor. Coyoteadapter - это адаптер, который адаптирует org.apache.coyote.request, инкапсулированный в рамках Coyote к org.apache.catalina.connector.request (я не буду много говорить об этом процессе, который был обобщен ранее). После преобразования метод ParsePathParameters будет вызван для анализа информации о файле cookie в параметрах пути (потому что, когда файл cookie отключена браузером, информация Cookie будет переписана в URL). Сначала попробуйте проанализировать SessionId с URL. Затем будет вызван ParsesessionCookiesId. Это следует анализировать SessionId из файла cookie и сохранить его в запросе (ParsePathParameters и методы ParsesessionCookiesId. В процессе вызова не видно очевидной логики XOR, то есть оба выполняются, но разве нет проблемы? без проблем). Разбор в SessionID и поместите его в запрос. Это нормально, чтобы проанализировать логику SessionId.
Опубликованы следующие коды ключей:
Метод ParsePathParameters (анализируется от rewrite url):
PS: отмеченные части представляют собой переменные анализа от URL -адреса, а затем помещают их в список параметров запроса.
Метод ParsesessionCookiesId (Sessing SessionId из файлов cookie):
PS: вышеупомянутый тег должен получить SessionID от cookie. Посмотрите на первый тег с Call to SessionConfig.getSessionCookiEname (контекст), здесь вы получите ключ от SessionId. Этот ключ определяется в SessionConfig, а его значение - JSessionId:
(2) Процесс получения сеанса из запроса в основном, как описано выше. Затем посмотрите на процесс получения сеанса в сервлете:
Обзор: AppServlet - это сервлет, который мы определяем себя. Когда мы получаем сеанс через Reqest, HttpservletRequest (интерфейс), который называется на самом деле requestFacade (фасад, который инкапсулирует org.apache.catalina.connector.request), а затем запросфакад вызовет метод Getsession реального запроса. Конкретная логика запроса состоит в том, чтобы вызвать метод GetManger контекстного контейнера, чтобы получить менеджер сеанса (подробности менеджера сеанса описаны ниже). Если SessionID был проанализирован, то метод поиска будет вызван для получения соответствующего сеанса из пула объектов сеанса. В противном случае, если SessionID не существует, необходимо воссоздать сессию и помещен в пул объектов сеанса.
Опубликованы следующие коды ключей:
Метод GetSession класса requestFacade:
Метод запроса класса GetSession:
Метод класса Dogetsession запроса:
PS: Первый тег - получить информацию о сеансе из пула объектов сеанса на основе SessionID, а второй тег - создать новый объект сеанса без анализа SessionID.
Это создает новую сессию. Этот момент включает в себя генерацию нового сеанса. Код логического ключа для генерации SessionID определяется в методе GeneratesessionID в генераторе сеанса класса:
Выше приведено процесс получения сеанса сервлета. Следующие детали обобщают, как Tomcat управляет сеансом, то есть знанием менеджера сеанса.
2. Механизм управления сеансом
Определение менеджера сеанса: Компонент менеджера сеанса отвечает за управление объектами сеанса, такие как создание и уничтожение объектов сеанса.
Во -первых, давайте посмотрим на диаграмму структуры наследования класса наследия менеджера сеанса (это график tocmat7.x, а механизм наследования класса Tomcat5 сильно отличается от этого)::
Краткое описание: Следующая суммирует каждую категорию по очереди (см. Официальную информацию о веб -сайте):
(1) Менеджер: определяет базовый интерфейс, связанный с определенным контейнером для управления пулом сеансов.
(2) ManagerBase: реализует интерфейс менеджера, который обеспечивает реализацию общих функций менеджера сеанса.
(3) StandardManager: наследует от ManagerBase, менеджера сеанса по умолчанию (не указав конфигурацию, используйте это по умолчанию). Это не кластерная реализация сеансов обработки Tomcat (то есть автономная версия). Когда Tomcat будет закрыт, информация о сеансе памяти будет сохраняться для диска и сохранена как Session.ser, и будет восстановлена при загрузке.
(4) PersistentManagerBase: унаследован от ManagerBase, реализует и определяет основные функции постоянства менеджера сеанса.
(5) PersistentManager: унаследован от PersistentManagerBase. Основная функция - обменять объекты сеанса холостого хода (установив время ожидания) на диск.
(6) ClusterManager: он реализует интерфейс менеджера, и вам следует угадать по имени класса. Это менеджер, который управляет сеансом кластера, и менеджер сессий стандартной версии StandardManager, выше, являются относительными понятиями. Этот класс определяет репликацию и обмен интерфейсом сеансов между классами.
(7) ClusterManagerBase: реализует интерфейс ClusterManager и наследует от ManagerBase. Этот класс реализует основную работу репликации сеанса.
(8) Backupmanager: унаследован от ClusterManagerBase, реализации стратегии репликации сеанса. В данных сеанса есть только один резервный узел, и все узлы в кластере видны в месте этого резервного узла. Этот дизайн дает ему преимущество в поддержке гетерогенных развертываний.
(9) Deltamanager: унаследован от ClusterManagerBase, реализация стратегии репликации кластера. В отличие от Backupmanager, данные сеанса будут скопированы на все узлы членов в кластере, что требует, чтобы все узлы в кластере должны были быть изоморфными, а одно и то же приложение должно быть развернуто.
Дополнение: давайте подробно рассмотрим его ниже. В классе PersistentManagerBase есть магазин переменных участников:
Стратегия хранения постоянного менеджера сеансов определяется этим объектом магазина. Структура наследования класса в этом магазине выглядит следующим образом:
Краткое описание: интерфейс -магазин и его примеры предоставляют набор стратегий хранения для менеджера сеанса. Магазин определяет базовый интерфейс, а магазин обеспечивает базовую реализацию. Политика, реализованная классом Filestore, заключается в хранении сеанса в файле, указанном в каталоге с SetDirectory () и заканчивается .session. Класс JDBCSTORE хранит сеанс в базе данных через JDBC. Следовательно, необходимо использовать JDBCSTORE. Вам необходимо вызвать метод SetDriverName () и метод setConnectionUrl () соответственно, чтобы установить имя драйвера и URL -адрес соединения.
3. Конфигурация, связанная с сеансом Tomcat
Суммируйте конфигурацию и настройки, связанные с сеансом с двух уровней. Прежде всего, с уровня файла конфигурации, сеанс имеет время истечения, и время истечения срока по умолчанию определяется в $ catalina_home/conf/web.xml. Конфигурация конкретной по умолчанию заключается в следующем (время истечения срока по умолчанию составляет 30 минут, то есть доступа за 30 минут нет, а сеанс истекает):
Другой момент заключается в том, что если управление сеансом не настроено, StandardManager используется по умолчанию. Однако, если вы хотите настроить его, вы можете указать его в $ catalina_home/conf/context.xml (из этой конфигурации вы можете увидеть, что диспетчер сеансов связан с контекстным контейнером, что означает, что в каждом веб -приложении будет диспетчер сеансов). Конкретная конфигурация заключается в следующем:
Tomcat7.x по умолчанию на конфигурацию этого менеджера. Если PersistentManager, который вы хотите указать, является менеджером по умолчанию, вы можете указать это так:
Фактически, увидев это, я обнаружил, что политика менеджера сессий или хранилища хранилища может быть настроена до тех пор, пока внедрено соответствующий интерфейс. Это нормально написать конфигурацию самостоятельно здесь.
Кроме того, давайте суммируем на уровне кода: некоторая информация о конфигурации сеанса записывается в коде, например, класс SessionConfig определяет некоторую информацию о настройке сеанса. Название сеанса в cookie - JSession. Когда сеанс помещается на путь через переписывание URL, название ключевого значения - JSessionIds. Конкретный код заключается в следующем:
Другой момент заключается в том, что указанная по умолчанию длина SessionID составляет 16 байт, что указано в SessionIdgenerator:
Хорошо, так много обобщено о конфигурации по умолчанию.
Выше всего содержание этой статьи. Я надеюсь, что это будет полезно для каждого обучения, и я надеюсь, что все будут поддерживать Wulin.com больше.