Introduction

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.