Session tracking in Java application | session concept in java

Plainly because HTTP is a stateless protocol. That means a Web Server handling HTTP requests doesn't maintain contextual info about the client requests coming to it. Putting it differently, the Web Server doesn't have a built-in way to recognize whether the current request is coming from a new client or from a client which has been communicating with it for a while now. This happens because every HTTP request is treated as an altogether new request.


As we can easily imagine that such a behavior can cause so many problems - for example, if a user has logged into his Bank Account and after a successful login if he wishes to go to the Funds Transfer page then he would be required to login again as Funds Transfer would be a login-protected page and the Web Server doesn't have any built-in support for recognizing if the clinet requesting this page is the one who is alraedy logged in or if it's coming from a new client. This is just a simple example... we can easily imagine how difficult will it be to develop a Web-Application without maintaining contextual information about the clients.


What are the various ways of tracking Sessions?


There are three ways of tracking sessions. In other words, there are three ways of maintaining contextual information about clients as a session is nothing but a collection of various information about the particular client the session has been built and maintained for. Three ways of session tracking in servlets are:-

    Using Cookies - Cookies are stored at the client side (in the browser's cache) and they are used to maintain the current session. Every cookie object stores contextual information for that particular session and it's always associated with a unique Session ID, which is sent to the server on creation of the cookie. The server uses that Session ID to locate the cookie at the clinet machine and then it uses the contextual information stored in that cookie object for various purposes including client authentication, client authorization, retrieving/saving data which the client may require in subsequent steps, etc. A timeout period for the cookie objects can be set after which they will become expired. Cookies may be a security threat as the Session ID may be used to track the particular cookie and then to retrieve secure information from it. This is the reason why all the browsers provide options to either enable or disable cookies at the user's discretion. You can simply disable Cookies by updating your browser options.

    Using URL Rewriting - This approach of maintaining sessions requires an extra peice of data to be appended to each URL. This extra info is used to identify the session and the server associates this identifier with the data it has stored for that particular session. The advantage of this approach is that it works even in those cases where the user has disabled cookied for their browsers. In this approach nothing is actually stored at the client side and all the sessio tracking info travels via URLs back and forth. SO, you may obviously lose the session information (the session would have been invalid due to timeout) if you bookmark an URL first and then try to access that later on.

    Using Hidden Form Fields - This is another approach of maintaining session where the contextual data travels via hidden form fields (<INPUT TYPE="hidden" ...). There are two main disadvantages of this approach: One, one can easily see all the data (maybe some secret info) by looking at the HTML Source of the page and Two, this approach will probaly work only for dynamic web pages (how would we maintain different session with unique identifiers otherwise?).