Frits Walraven wrote:Yes, that is correct. The Servlet 3.0 specifications do not specify that a servlet container should persist Sessions so that they could be revived after a crash.
If the server goes down, or there is a timeout (Session timeout), or the HttpSession.invalidate() method is called are all examples of when a session will be removed.
hey frits but even if we restart tomcat and make a request it retains the session. I think even if server goes down it will retain the session. What do you say ?
Creator of Enthuware JWS+ V6
So since it is not mandated by the specs.Then the only example when a session will be removed is Session timeout, or the HttpSession.invalidate() right ?
Just few post before you specified that "even if the server goes down, the session will be removed" ???
Yes, you are right. The Session timeout and calling the invalidate() method are for sure causing the Session to end. What should happen when a server shuts down is not really fully specified.
The only thing you can find what should happen is this:
11.3.4 Notifications At Shutdown On application shutdown, listeners are notified in reverse order to their declarations with notifications to session listeners preceding notifications to context listeners. Session listeners must be notified of session invalidationsprior to context listeners being notified of application shutdown
From this you could argue that the active Sessions should be removed before the application context is removed....
Just add both Session and Context listeners to your web-app and tell us what happens on shutdown (stop the server)
listeners are notified in reverse order to their declarations with notifications to session listeners preceding notifications to context listeners
I get it that session listeners are notified before context listeners what i dont get is this part of the statement in reverse order to their declarations I mean if the context listeners are always gonna get executed after session listeners during shutdown then why is the order necessary in DD ?? Sorry but i dont get it ? can you elaborate this a little ?
And I was reading regarding this thing and i came across with this statement
"The order of listener is defined in D.D " I mean does the order of the listeners gonna specifies how the listeners gonna be implemented.How ? i mean if there is session listener and context listeners they are always gonna be
executed when the EVENT occurs.
Can you also please explain this ?
Also i came across this which was specified in one of the threads
"Most of the listeners behave similar in single context as well as in multiple contexts(distributed environments) with the major difference is when a context is destroyed due to server crashes in distributed environemnt, the session in that context is exported to another available context. "
So now according to that session wont be destroyed if the server crashes. I hope this is right ? let me know ? and also please explain me regarding the other doubts that i have mentioned above.
Creator of Enthuware JWS+ V6
I mean if the context listeners are always gonna get executed after session listeners during shutdown then why is the order necessary in DD ?? Sorry but i dont get it ? can you elaborate this a little ?
The order comes into play when you have for instance 2 Session listeners with a sessionCreated method. The order of which listener to start first is in what order they appear in your web.xml , so:
When a Session is created the sessionCreated method of HttpSessionOne is called before the sessionCreated method of HttpSessionTwo because it is defined earlier.
When shutting down the sessionDestroyed method of HttpSessionTwo will be called before the one of HttpSessionOne (that is the reverse order they are talking about)