<session-config>
<session-timeout>30</session-timeout>
</session-config>
HTTP Session & Timeout
Столкнулся с проблемой. При подключении через браузер к сервлетному веб-приложению - создается новая HTTPSession в которой хранятся некоторы данные, текущее состояние до которого пользователь добрался при работе с этим приложением.
Так вот, если пользователь на час или более уйдет чай пить, а потом вернется, то при этом веб-сервер убивает HTTP Session вместе с текущим состоянием - в результате пользователь потеряет все свои данные.
Кто-то посоветовал сделать скрытый frame, в котором будут посылаться submit'ы на сервер для поддержки HTTP Session, скажем так, каждые 10 мин.
Но, почему-то в некоторых случаях это не помогает.
Так что вопрос:
1. Правильный ли это подход и как из web-приложения узнать Timeout на сессию (10 мин, это просто попытка угадать его, а хотелось бы знать поточнее, чтоб наверняка)
2. Если этот подход не правильный или помогает не во всех случаях. То как нужно поступать?
Так вот, если пользователь на час или более уйдет чай пить, а потом вернется, то при этом веб-сервер убивает HTTP Session вместе с текущим состоянием - в результате пользователь потеряет все свои данные.
Кто-то посоветовал сделать скрытый frame, в котором будут посылаться submit'ы на сервер для поддержки HTTP Session, скажем так, каждые 10 мин.
Но, почему-то в некоторых случаях это не помогает.
Так что вопрос:
1. Правильный ли это подход и как из web-приложения узнать Timeout на сессию (10 мин, это просто попытка угадать его, а хотелось бы знать поточнее, чтоб наверняка)
2. Если этот подход не правильный или помогает не во всех случаях. То как нужно поступать?
Попробуй воспользоваться Session Tracking API:
public void setMaxInactiveInterval(int seconds)
public void setMaxInactiveInterval(int seconds)
Спасибо за советы. Но проблема разрешилась.
В вышеописанном скрытом фрейме я делал еще некоторые манипуляции, которые на стороне сервера приводили к обращению к некоторым Java Bean'ам, где, в свою очередь, после некоторых доработок вылетало Null Pointer Exception. В результате чего в скрытом фрейме было не то, что должно было быть. Вот и не срабатывала схема.
Попутно нашел, что время жизни HTTP сессии можно задавать в web.xml, вот пример:
В вышеописанном скрытом фрейме я делал еще некоторые манипуляции, которые на стороне сервера приводили к обращению к некоторым Java Bean'ам, где, в свою очередь, после некоторых доработок вылетало Null Pointer Exception. В результате чего в скрытом фрейме было не то, что должно было быть. Вот и не срабатывала схема.
Попутно нашел, что время жизни HTTP сессии можно задавать в web.xml, вот пример:
Код:
на мой взгляд, запросы из скрытого врейма - наиболее непрофессиональный из указанных здесь подходов.
Цитата:
Originally posted by gufy
на мой взгляд, запросы из скрытого врейма - наиболее непрофессиональный из указанных здесь подходов.
на мой взгляд, запросы из скрытого врейма - наиболее непрофессиональный из указанных здесь подходов.
А какой подход выбрать?
С одной стороны - пользователь открыл браузер, поработал, и, не закрывая браузера, ушел в пятницу вечером домой. Вернулся в понедельник - ему бы хотелось продолжить работать.
С другой стороны, если пользователь закрыл браузер, то держать на сервере состояние его HTTP сессии не целесообразно - зря тратятся ресурсы веб-сервера.
Помоему это правильный подход (с эмуляцией активности пользователя для поддержки HTTP сессии). Другого я просто не вижу.
неправильный посыл ведет, на мой взгляд, к неправильным выводам :)
Цитата:
Вернулся в понедельник - ему бы хотелось продолжить работать.
странный такой юзер! ушел, оставив на 2,5 суток включенным комп с открытым браузером, да? не, это неправильно. закончил работать - заканчивай. иначе в СЕССИИ смысла просто нет. раз есть данные, которые нужно хранить между сессиями, то при любом из изменении их нужно бэкапить.
как сработает твой подход, если у меня на самом интересном месте работы вдруг моргнет электричество и комп попросту выключится? тут-то уже никакие искусственные приемы не сработают!
т.е., на мой взгляд: выставь в web.xml какой-то разумный TimeOut на сессию, и при любых изменениях данных, которые нужно между сессиями хранить, бэкапь их так, как делаешь это при закрытии сессии естетсвенным путем (закрытии браузера).
Цитата:
Originally posted by gufy
странный такой юзер! ушел, оставив на 2,5 суток включенным комп с открытым браузером, да? не, это неправильно. закончил работать - заканчивай. иначе в СЕССИИ смысла просто нет. раз есть данные, которые нужно хранить между сессиями, то при любом из изменении их нужно бэкапить.
странный такой юзер! ушел, оставив на 2,5 суток включенным комп с открытым браузером, да? не, это неправильно. закончил работать - заканчивай. иначе в СЕССИИ смысла просто нет. раз есть данные, которые нужно хранить между сессиями, то при любом из изменении их нужно бэкапить.
Ну тут уже не от меня зависит, сколько времени юзер чай пьет, хоть 10 мин, хоть 3 дня. Но требование от юзеров именно такое.
Цитата:
как сработает твой подход, если у меня на самом интересном месте работы вдруг моргнет электричество и комп попросту выключится? тут-то уже никакие искусственные приемы не сработают!
т.е., на мой взгляд: выставь в web.xml какой-то разумный TimeOut на сессию, и при любых изменениях данных, которые нужно между сессиями хранить, бэкапь их так, как делаешь это при закрытии сессии естетсвенным путем (закрытии браузера).
т.е., на мой взгляд: выставь в web.xml какой-то разумный TimeOut на сессию, и при любых изменениях данных, которые нужно между сессиями хранить, бэкапь их так, как делаешь это при закрытии сессии естетсвенным путем (закрытии браузера).
И в товоем случае, если моргнет электричество, пользователь после перезагрузки запустит новый браузер - а новый браузер - это новая HTTP сессия. И доступа к данным из старой он не получит (хоть ей TimeOut в 1 год выставить).
По поводу "искусственные приемы не сработают" - это не совсем так. В этом случае делается вот так:
1. При создании новой HTTP сессии - генерим некий уникальный идентификатор. Записываем его в cookies на клиенте.
2. В некотором статическом мапе делаем мап с этого идентификатора на объект-состояние данной HTTP Session.
3. Если пользователь закрыл браузер (например в результате отключения электричества), то при повторном запуске браузера для вновь созданной HTTP сессии ищем по идентификатору из куков в нашем статическом мапе объект-состояние и помещаем его в новую HTTP сессию - и пользователь в принципе может продолжить работу.
4. Тут нужно решить, сколько жить одной записи в этом статическом мапе (например можно синхронизировать со временем жизни HTTP сессии).
Но опять, таки по просьбе все тех же юзеров - им это не надо.
И еще, при закрытии браузера HTTP сессия мрет по TimeOut'у...
Цитата:
Originally posted by gufy
раз есть данные, которые нужно хранить между сессиями, то при любом из изменении их нужно бэкапить.
раз есть данные, которые нужно хранить между сессиями, то при любом из изменении их нужно бэкапить.
Что то я не понял? Разве я где-то говорил, что мне обязательно нужно данные хранить между сесссиями. Вопрос изначально стоял так: открыли браузер, поработали, отошли (на 5 мин, на час, на год), вернулись обратно - пытаемся продолжить, но ничего не выходит, потому что на сервере TimeOut для HTTP сесси установлен на меньшее время, чем ушел пользователь.
Мне нужно было решить именно эту задачу: запущен браузер - работаем хоть с годовыми перерывами. Закрыли браузер - все теряется...
подожди, ты сам себе противоречишь! вначале
Цитата:
Закрыли браузер - все теряется...
а потом
Цитата:
в нашем статическом мапе объект-состояние и помещаем его в новую HTTP сессию - и пользователь в принципе может продолжить работу.
вот про второй случай, т.е. бэкап данных, я как раз и говорил.
ну, а первый случай - просто поставь разумный таймаут (ну, скажем, неделю! вряд ли кто-то дольше просидит с открытым браузером) - тогда и юзерам хватит, и сервер не будет лишнего хранить.
т.е. ты определись, будешь данные хранить на случай пожара, или нет.
Цитата:
Originally posted by gufy
подожди, ты сам себе противоречишь! вначале skipped
подожди, ты сам себе противоречишь! вначале skipped
Да вообще-то не противоречу. Я говорю вот что:
Нужно сделать так, чтобы когда браузер открыт - ничего не терять по TimeOut'у. Когда браузер закрывается - данные должны очистится по TimeOut'у (который не должен быть слишком большим). Ну так все-таки, кроме как пользовать скрытый фрейм для эмуляции активности для поддержания HTTP сессии есть еще варианты? А то Вы назвали такой подход непрофессиональным. Еще раз замечу - задача стоит именно так, как я описал. И не я это придумывал - мое дело реализовать.
А про сохранения, про статические мапы итп - я просто привел контраргумент на Вашу фразу, что "тут-то уже никакие искусственные приемы не сработают". И сразу же добавил, что такое поведение нашего заказчика не устраивает...