Session & cookie

Identifying Client:
         In web pages where a particular set of process has to be carried out, the client has to be identified by the container (server). Being a stateless transfer protocol, HTTP does not store the state of client. In other words, does not remember the client to which it respond previously. The container does not know that it was the same client which requested before. Each request will be considered as a new request.

Trump Card:

         The trump card for the problem is the "session", which is responsible for identifying a client by the container. Session is used by container to identify the client as , it was the previous one i was responded

          Container identifies each client by assigning a unique session id. This session id was exchanged between client and container. . Container has to informed to do so when required. Of all the methods available to exchange session id between client and container, using cookie was the simplest and common method. Once a cookie is set, it will automatically exchanged between client and container unless client ignores storing cookie.

Cookie:

          Cookie is a small piece of date represented as a name:value; string. Cookie was transmitted between client and server. Client need not do anything to establish or manage cookie. For each request made from the client it was done automatically. Usually, once the client was closed, the cookie will be destroyed. But it can be set to remember if client has such provisions.

          Sending cookie and header in the response are both different deals. For sending header name value pairs are passed like response.addHeader("name", value);. But for sending cookie, the cookie object was sent instead like response.addCookie(cookieObject);

 How Container manage cookie?

• Creates cookie object
• Creates session id
• Stuff session id into cookie object
• Set cookie as a part of response
• Identifies and matches the cookie value in further requests.

HTTP Session Methods:

• getCreationTime()
• getLastAccessedTime()
• setMaxInactiveInterval()
• getMaxInactiveInterval()
• invalidate()

Three ways the session can be destroyed:

• After the specified session expiry time
• After the call of invalidate() function
• After the web-application goes down

          Session time out duration can be set in DD. Parameter is specified in-terms of minutes.

          If time-out value of any one session has to be modified, they modify that particular session alone using the syntax

setMaxInactiveInterval(mins * 60);

Note: Here it is specified in seconds.

setting setMaxInactiveInterval as 0 is equivalent to calling invalidate() on that particular session.

Session Life Cycle Events:
          A session undergoes various milestone during its life cycle. During each stage it pass through events and its corresponding milestones.
Milestone: Life Cycle i.e. Session Created or Destroyed
Event: HttpSessionEvent
Listener:HttpSessionListener

Milestone: Attributes i.e. when an attribute is added, removed & replaced
Event: HttpSessionBindingEvent
Listener: HttpSessionAttributeListener

Milestone: Migration i.e. when a session is about to passivated or activated
Event: HttpSessionEvent
Listener: HttpSessionActivationListener