Сессии Tomcat / jBOSS - где они обычно хранятся?

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

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

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

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

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

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

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

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

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

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

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

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

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

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