Размер и время жизни сеанса сервлета

Question

1) Каков допустимый диапазон размеров объектов, которые должны быть присоединены к сеансу? Если я присоединяю объект, который может быть 5 КБ, и у меня есть 10 КБ действительных сессий в любой момент времени, это 50 МБ памяти, что мне кажется приемлемым. Это правильный способ решения проблемы или есть другие существенные проблемы?

2) Это, вероятно, глупый вопрос, но если я присоединяю объект к сеансу с продолжительностью 2 недели, могу ли я получить доступ к атрибуту, как если бы он находился в памяти на протяжении всей продолжительности сеанса?

3) Есть ли причина НЕ сохранять данные сеанса в БД?

Answer 1

1. Java EE не ограничивает размер HTTP-сессии. Требования к оперативной памяти для вашего веб-приложения будут равны x + su * s, где «x» - это все остальное, «su» - максимальное количество одновременных пользователей сеанса, а «s» - сам размер объекта сеанса. Так что, если это приложение не более 5 пользователей, пойти на это. Если у него 1500 пользователей, вы можете пересмотреть. Время, необходимое для сериализации / десериализации каждого объекта сеанса, будет увеличиваться более или менее линейно с размером объекта. Так что, если ожидается много последовательных преобразований, будьте готовы.
2. Вы можете, пока ваша сессия жива.
3. Сохранение данных сеанса является дорогостоящим с точки зрения производительности, вы должны делать это только тогда, когда вам нужна репликация сеанса в кластере для целей восстановления.

Answer 2

1. Приемлемый размер зависит от вашего варианта использования и количества одновременных сеансов.Если ваши сеансы длятся 2 недели, то вполне возможно, что у вас может быть много одновременных сеансов, но если ваш максимальный антиадгезив равен 10k, то не должно быть проблем с объектом сеанса 5k (как показывает ваш расчет).

2. Пока у вас есть ссылка на объект сеанса (или вы можете получить такую ​​ссылку), данные будут сохраняться в сеансе.Помните, что ваши объекты сеанса должны быть сериализуемыми.

3. Возможно, вы не захотите сохранять все данные сеанса в БД по соображениям производительности, особенно если данные сеанса могут быть легко воссозданы.