У меня есть вопрос о Tomcat / jBOSS и других серверах приложений Java. Где хранятся сеансы (данные сеансов)?
По умолчанию я бы сказал в памяти. Детали на самом деле ... детали реализации, которые зависят от сервера приложений.
В PHP сеансы обычно хранятся в базе данных, что означает, что вы можете легко обмениваться данными сеанса в среде с балансировкой нагрузки. В Tomcat и других серверах приложений сеанс, по-видимому, по умолчанию хранится в памяти, что не применяется в среде с балансировкой нагрузки.
Ну, не совсем. Это означает, что клиентский запрос должен отправляться на тот же узел в кластерной среде (это называется «привязкой сеанса»), и это не проблема с точки зрения балансировки нагрузки. Но это проблема с точки зрения аварийного переключения: в случае сбоя узла в кластере состояние сеанса, управляемое узлом, может быть потеряно. Чтобы решить эту проблему, почти все поставщики серверов приложений реализуют аварийное переключение сеансов (используя различные механизмы, такие как репликация в памяти, постоянство на основе JDBC и т. Д.). Но, опять же, детали реализации зависят от сервера приложений. Посмотрите, например, как Tomcat или WebLogic справляются с этим. Статья Under the Hood of J2EE Clustering на стороне сервера - тоже очень интересное чтение.
Хотя PHP и хранит сессии в файлах по умолчанию, для его подключения к БД требуется несколько строк. То же самое относится и к серверам приложений?
Как я уже сказал, не все серверы приложений будут поддерживать постоянство на основе JDBC. Сказав это, и чтобы ответить на ваш вопрос, конфигурация, как правило, проста, когда они это делают. Но использование базы данных на самом деле не является предпочтительным решением (на самом деле, я избегаю его любой ценой).
В основном, каковы плюсы для сеансов рассказывания историй в памяти? Это все еще стандартная практика для серверов приложений?
Просто: производительность! Сериализация данных, вызов базы данных, запись на диск - все это имеет свою стоимость. Репликация в памяти, очевидно, позволяет избежать некоторых накладных расходов. Но это тоже имеет некоторые ограничения. Например, он не позволяет Репликация состояния сеанса WAN HTTP с WebLogic. Но ну, мало кому это нужно:)