Chapt 6 Conversational state
-
An HttpSession object can hold conversational state across multiple requests from the same client, in orther words it persists for an entire session with a specific client, we can use it to store everything we get back from the client in all the request the client makes during a session.
-
On the client’s first request, the Container generates a unique session ID and gives it back to the client with the response, the client ?sends back the session ID with each subsequent request, the container sees the ID, finds the matching session, and associates the session with the request.
-
The container has to get the sesseion ID to the client as part of the response, and the client has to send back the session ID as part of the request, the simplest and most common way to exchange the info is through cookies.
-
If the client won’t take cookies, we can use URL rewriting as a back-up. URL rewriting is automatic, but only if you encode your URLs, you have to run all your URLs through a method of the response object-encodeURL() or encodeRedirectURL()-and the container does everything else. URL encoding is all about the response.
-
URL rewriting adds the session ID to the end of the URLs in the HTML that you write to the response; The seesion ID then comes back with the request as “extra” info at the end of the request URL; URL rewriting will happen automatically if cookies don’t work with the client, but you have to explicitly encode all of the URLs you write; To encode a URL, call response.encodeURL(aString); There’s no way to get automatic URL rewriting with your static pages, so if you depend on sessions, you must use dynamically-generated pages.
-
Three ways a session can be got rid of stale sessions: 1.It times out; 2.You call invalidate*( on the session object; 3.The application goes down.
-
Specify timeouts in the DD using MINUTES, but if we set a timeout programmatically, we speciy SECONDS.
-
We can use cookies to exchange name/value String pairs between the server and the client, the servlet sends the cookie to the client, and the client sends it back with each subsequent request, session cookies vanish when the client’s browser quits, but you can tell a cookie to persist on the client even after the browser shuts down.
-
Only HttpSession objects move from the VM to another, there is one servletcontext per VM, there is one ServletConfig per servlet, per VM, but there is only one HttpSession object for a given seesion ID per web app, regardless of how many VM’s the app is distributed across.
-
Each servlet has its own ServletConfig, and both servlet in the web app share a ServletContext, everything except the HttpSession is duplicated on the other VM, everything is duplicated in the second server except the HttpSession objects, sessions live in only one place at any given moment, the same session ID for a given web app will never appear in two VMs at the same time.
-
If you need to save and restore instance variable state in your attrivute, use HttpSessionActivationListener, and use the two event callback(sessionDidActivate() and sessionWillPassivate()) the way(This is serialization) you’d use readObject() and writeObjest().