Есть ли способ указать другое хранилище сеансов с Tomcat?
Tomcat (здесь версия 5) хранит информацию о сеансе в памяти. При кластеризации эта информация периодически транслируется на другие серверы в кластере для синхронизации. Вы можете использовать хранилище базы данных, чтобы сделать сеансы постоянными, но эта информация также записывается только периодически и действительно используется только для восстановления после сбоя, а не для фактической замены сеансов в памяти.
Если вы не хотите использовать липкие сеансы (наша конфигурация, к сожалению, этого не позволяет), возникает проблема рассинхронизации сеансов.
На других языках веб-фреймворки, как правило, позволяют использовать базу данных в качестве основного хранилища сеансов. Хотя это создает потенциальную проблему масштабирования, но делает управление сеансом очень простым. Мне интересно, есть ли способ заставить tomcat использовать базу данных для сеансов таким образом (технически это также устранит необходимость в какой-либо конфигурации кластеризации в tomcat server.xml).
Ответы 4
Взгляните на Терракотовый, я думаю, он может решить ваши проблемы с масштабированием без серьезного изменения дизайна приложения.
Способ определенно есть. Хотя я бы решительно проголосовал за липкие сеансы - это экономит столько нагрузки на ваши серверы / базу данных (если что-то не выходит из строя) ...
http://tomcat.apache.org/tomcat-5.5-doc/config/manager.html содержит информацию о конфигурации и настройке SessionManager для Tomcat. В зависимости от ваших конкретных требований вам может потребоваться реализовать собственный менеджер сеансов, но эта отправная точка должна оказать некоторую помощь.
Я всегда был поклонником техники сеансов Rails: храните сеансы (зашифрованные + зашифрованные + подписанные) в cookie пользователя. Таким образом, вы можете выполнять балансировку нагрузки в соответствии с вашими сердцами, и вам не нужно беспокоиться о липких сеансах или попадании в базу данных для данных сеанса и т.д. переписывания вашего кода доступа к сеансу. Во всяком случае просто мысль.
Размер и количество файлов cookie очень ограничены. Максимум ~ 20 файлов cookie на домен и максимум ~ 4 КБ на файл cookie.
Как Rails справляется с ограниченным размером файлов cookie?
Другой альтернативой может быть memcached-сеанс-менеджер, решение для отработки отказа сеанса и репликации сеанса на основе memcached для tomcat 6.x / 7.x. Он поддерживает как липкие, так и не липкие сеансы.
Я создал этот проект, чтобы добиться максимальной производительности и надежности, а также иметь возможность масштабирования, просто добавляя дополнительные узлы tomcat и memcached.
Если вы не используете липкие сеансы, вы нарушаете одно из требований спецификации сервлета - запросы для одного и того же сеанса обслуживаются одной и той же JVM. Tomcat делает это очень сложно. Вы, вероятно, столкнетесь с проблемами потери обновлений при хранении сеансов в базе данных.