Как вызвать sessionDestroyed, когда время сеанса истекло

Question

Я новичок в JSP. Я использовал следующий код в классе, который реализует HttpSessionListener, чтобы получить SESSION OUT, когда время сеанса истекло:

    public void sessionCreated(HttpSessionEvent arg0) {  
        System.out.print("SESSION Created");
    }

    public void sessionDestroyed(HttpSessionEvent arg0) {
        System.out.print("SESSION OUT");
    }

и я установил web.xml:

  <session-config>
     <session-timeout>1</session-timeout> 
  </session-config>

Сервлет ждет более двух минут, затем вызывает sessionDestroyed.

Есть ли способ заставить sessionDestroyed по истечении времени ожидания?

Заранее спасибо.

Answer 1

Сервлет ждет более двух минут, затем вызывает sessionDestroyed.

Есть ли способ принудительно уничтожить сессию после истечения времени ожидания?

Это зависит от реализации (зависит от сервера приложений). Существует фоновый поток, который проверяет сеансы через определенные промежутки времени и собирает все просроченные. Это может происходить каждую минуту, но также может происходить каждые 15 минут. Они также будут немедленно получены, если вы выполните запрос, когда соответствующий сеанс уже истек, но еще не получен.

Таким образом, если вы, например, подождите одну минуту и ​​сгенерируете новый запрос, он будет немедленно получен. Там действительно не нужно беспокоиться об этом. Вам не нужно заставлять его пожинать их немедленно, это было бы дорогостоящей задачей. Вы знаете, все дело в программировании, а не в магии;)

Answer 2

Что заставляет вас думать, что sessionDestroyed не вызывается , когда сеанс истекает? Или, другими словами, как вы интерпретируете тот факт, что его вообще называют?

Сервлет будет обрабатывать достоверность сеансов по-своему, включая время ожидания сеанса, и когда он определит, что сеанс больше не является действительным, он вызовет ваш метод. Однако я не думаю, что какие-либо сервлеты гарантируют какую-либо конкретную своевременность в этом отношении; Насколько я понимаю, это немного похоже на сборку мусора в том смысле, что она гарантированно произойдет в какой-то момент , но не обязательно в самом раннем возможном случае, когда сеанс станет пригодным для уничтожения.

В любом случае кажется почти уверенным, что сервлет делает то, что вы хотите - видя, что время сеанса истекло, и вызывая соответствующий метод - единственный вопрос в том, увидите ли вы это точно через 60 секунд после последний запрос или чуть позже. Я бы сказал, что в общем случае вы не должны полагаться на точные моменты времени, когда этот метод вызывается; конечно, используйте его для очистки ресурсов, но не для чего-то вроде корректности программы (в любом случае вы получите IllegalStateExceptions, если вызовете методы в недопустимом сеансе). Если вы чувствуете, что действительно должны полагаться на это, возможно, объясните, что вы делаете, чтобы другие могли предложить более подходящие способы достижения этого.

Answer 3

когда вы заставляете пользователя выйти из системы с помощью метода invalidate (), который вызывается методом sessionDestroyed () HttpSessionListener, дважды, один раз при выходе из системы, и второй раз после некоторого задержанного периода времени. Это происходит, если после выхода из системы вы перенаправляете пользователя обратно на веб-страницу в вашем приложении. По сути, вы запускаете другой сеанс (который может быть неочевидным, если вы не добавили требования безопасности / аутентификации для всех своих веб-страниц), а отложенный второй вызов метода sessionDestroyed () является тайм-аутом. Простое решение, при выходе из системы перенаправить пользователя на веб-страницу за пределами вашего приложения. Читать эту статью сеанс

Answer 4

Я не думаю, что спецификация J2EE дает какие-либо гарантии относительно того, когда будут вызываться методы в слушателе. Это просто заявляет, что они будут вызваны в некоторый момент.

Я видел код, который работал на одном контейнере (Tomcat), но не работал на другом контейнере (OC4J). Разработчики сделали неверное предположение о том, когда будет вызван метод sessionDestroyed.

UPDATE

Обратите внимание, что поведение этого интерфейса изменилось в v2.4 спецификации сервлета. Подробнее см. стр. 21 .