Сессии Tomcat / jBOSS - где они обычно хранятся? - PullRequest
2 голосов
/ 17 декабря 2009

Предисловие: я не Java-разработчик.

У меня есть вопрос о Tomcat / jBOSS и других серверах приложений Java. Где хранятся сеансы (данные сеансов)? В PHP сессии обычно хранятся в базе данных, что означает, что вы можете легко обмениваться данными сессии в среде с балансировкой нагрузки. В Tomcat и других серверах приложений сессия, по-видимому, хранится в памяти по умолчанию, что не будет применяться в среде с балансировкой нагрузки. Хотя по умолчанию PHP хранит сессии в файлах по умолчанию, требуется несколько строк, чтобы подключить его к БД. То же самое относится и к серверам приложений?

В принципе, каковы плюсы для историй сессий в памяти? Это все еще стандартная практика для серверов приложений? Спасибо всем!

Ответы [ 3 ]

14 голосов
/ 17 декабря 2009

У меня есть вопрос о Tomcat / jBOSS и других серверах приложений Java. Где хранятся сеансы (данные сеансов)?

По умолчанию я бы сказал в памяти. Детали на самом деле ... детали реализации, которые зависят от сервера приложений.

В PHP сеансы обычно хранятся в базе данных, что означает, что вы можете легко обмениваться данными сеанса в среде с балансировкой нагрузки. В Tomcat и других серверах приложений сеанс, по-видимому, по умолчанию хранится в памяти, что не применяется в среде с балансировкой нагрузки.

Ну, не совсем. Это означает, что клиентский запрос должен отправляться на тот же узел в кластерной среде (это называется «привязкой сеанса»), и это не проблема с точки зрения балансировки нагрузки. Но это проблема с точки зрения аварийного переключения: в случае сбоя узла в кластере состояние сеанса, управляемое узлом, может быть потеряно. Чтобы решить эту проблему, почти все поставщики серверов приложений реализуют аварийное переключение сеансов (используя различные механизмы, такие как репликация в памяти, постоянство на основе JDBC и т. Д.). Но, опять же, детали реализации зависят от сервера приложений. Посмотрите, например, как Tomcat или WebLogic справляются с этим. Статья Under the Hood of J2EE Clustering на стороне сервера - тоже очень интересное чтение.

Хотя PHP и хранит сессии в файлах по умолчанию, для его подключения к БД требуется несколько строк. То же самое относится и к серверам приложений?

Как я уже сказал, не все серверы приложений будут поддерживать постоянство на основе JDBC. Сказав это, и чтобы ответить на ваш вопрос, конфигурация, как правило, проста, когда они это делают. Но использование базы данных на самом деле не является предпочтительным решением (на самом деле, я избегаю его любой ценой).

В основном, каковы плюсы для сеансов рассказывания историй в памяти? Это все еще стандартная практика для серверов приложений?

Просто: производительность! Сериализация данных, вызов базы данных, запись на диск - все это имеет свою стоимость. Репликация в памяти, очевидно, позволяет избежать некоторых накладных расходов. Но это тоже имеет некоторые ограничения. Например, он не позволяет Репликация состояния сеанса WAN HTTP с WebLogic. Но ну, мало кому это нужно:)

3 голосов
/ 17 декабря 2009

С помощью диспетчера сеансов сеанс всегда находится в памяти, но в нем есть менеджер для сохранения сеанса в хранилище JDBC,

http://tomcat.apache.org/tomcat-5.5-doc/config/manager.html

В отличие от PHP, сеанс по-прежнему доступен из памяти, и он сохраняется в БД только при достижении предела памяти или при завершении работы сервера. Так что ваш балансировщик нагрузки должен иметь липкую маршрутизацию, чтобы это работало.

Преимущество сеанса в памяти заключается в производительности, поскольку доступ к базе данных происходит не для каждой транзакции.

Вы можете написать собственный менеджер сессий для имитации поведения PHP.

1 голос
/ 17 декабря 2009

Спецификация JavaEE не диктует это, это зависит от индивидуальных реализаций. Например, обычным способом обработки балансировки нагрузки в Tomcat является использование реплицированных сеансов , где данные сеанса являются многоадресными между узлами. Хранение данных сеанса в базе данных является огромным фактором снижения производительности, и хотя Tomcat может поддерживать его, я действительно не рекомендую его.

...