Web server forget what you are, after sending a response
HTTP is stateless: When it gets a page request, it has no memory of any previous requests from the same client This makes it difficult to hold a conversation Typical example: Putting things one at a time into a shopping cart, then checking out--each page request must somehow be associated with previous requests The server must be able to keep track of multiple conversations with multiple users Session tracking is keeping track of what has gone before in particular conversation Since HTTP is stateless, it does not do this for you We have to do it yourself, in your servlets
Options to track Clients Interaction Use a stateful session enterprise java bean Every time requests comes in, servlet should locate clients stateful bean. Use a database Store user information in database. Use an HttpSession Its object can hold conversational state across multiple requests from the same client. URL rewriting - If client wont take cookies, you can use URL rewriting as a backup. Hidden <form> fields - It can be used to store a unique ID. - HTML forms can have an entry like the <INPUT TYPE="HIDDEN" NAME="session" VALUE="a1234"> This entry means that, when the form is submitted, the specified name and value are automatically included in the GET or POST data. -Not applicable to static pages. Only works for dynamic pages generated after form submission.
How Sessions works Problem : How does container know who the client is Idea is simple : On first request the Container generates a unique session ID and gives it back to the client.
Then client sends back the session ID with each subsequent request.
Container seees the ID, finds the matching session and associates the session with the request. How client and Container exchange Session ID Container generates session ID for the client as a part of response
Client has to send back the session ID as a part of request.
Simplest way is cookies.
Container does all cookie work HttpSession session=request.getSession(); This method creates a session, it also cause cookie to be sent with the response for the first time.
-we dont generate unique session ID -we dont make the new Cookie object -we dont associate the session ID with the cookie. -we dont set the Cookie into the response
To know whether session already been created or not getSession() returns a session regardless of whether theres a pre-existing session.
Way to know if the session is new is to ask the session - if (session.isNew())
isNew() returns true if the client has not yet responded with this session ID.
What if Client doesnt accept a Cookie : URL rewriting isNew() method will always return true if the cookies are not enabled.
URL rewriting -add the session ID to the end of all the URLs in the HTML we send back in the Response.
URL rewriting kicks in ONLY if cookies fail, and ONLY if we tell the the response to encode the URL.
out.print(<a href=\ + response.encodeURL (/Test.do) + \> click me </a>);
When to deactivate session Two ways for session timeout 1) Configuring session timeout in the DD <session-config> <session-timeout>15 </session-timeout> </session-config> 2) Setting session timeout for a specific session session.setMexInactiveInterval (20*60);
Three ways a session can die: 1) Its time out
2)We call invalidate() on the session object
3) The application goes down (crashes) Summary Even if HTTP is stateless we can keep track of clients previous interactions by using HttpSession, Cookies, URL rewriting.
Sessions, Cookies, URL rewriting all are handled by Container.
URL rewriting works only when cookies are disabled.