Session Management

Nobody likes providing a username and password every time he moves to a different page. Consider that you are shopping online. You select a few things that you would like to have. You now navigate to another page containing a different set of items. Finally when you are done with selecting items, you find that none of the items that you selected were saved. The application was not able to maintain a “conversational state” with you.

The http protocol does not provide a way to maintain a conversational state between the client and the server. Therefore we need some technique to maintain a conversational state. There are many ways of maintaining a “conversational state” between the client and server. Let me list out the common ones –

• Hidden Fields
• URL Rewriting
• Cookies
• HttpSession

Among these the HttpSession belonging to the Servlet API is the most popular method. There are times when the HttpSession would not help you, for example you would like to save customers preferences over a period of time so that the next time he visits your page you can load his preferences, in this case it would be better to use the concept of Cookies. Anyways, in this little tutorial I would tell you how the server is able to maintain a conversational state using the HttpSession technique.

Consider a client sends a request to a servlet. The servlet realizes that it needs to save the state of the client until the client decides to leave the application. It now retrieves the HttpSession object using the request.getSession() method. At this point the container checks if a session has already been created for the client. If not it creates a new session for the client. That is it! Right? No! You need to know more of it. What do you ever mean by “a session is created”? Shouldn’t the container have some method to identify repeated requests from the same client? So it does.

The container creates a unique session id for the client which is generally named as the JSESSIONID. When the response is sent it appends the session id to the response header as a cookie –
Set-Cookie: JSESSIONID=FSDGSDG13213.
The session id can be anything. After this each time the client sends the request to the container, the container identifies the client using the JSESSIONID. Now what happens if cookies are disabled on the client side? Session would not be saved? I had the same question. But after implementing a simple servlet, with cookies disabled, I found that the session was still maintained. After a few google searches I found that the cookies are stored in the server memory and not on the client side. Now again you might have a question on the cookies that are stored for a longer period. Will the server keep it for such a long time? No, when you specify a maximum age for the cookie using the setMaxAge() method, the cookie is written into a file and saved on the client machine(provided cookies are enabled on the client browser).

How do you invalidate the session? Either you set the maximum age that it should live (setMaxAgeInterval() ), or you do it explicitly (session.invalidate()).
There is a lot more on session management that I found very interesting on the HFSJSP. And please take a look on how sessions should be handled if the cookies are disabled even on the server side (can you do it? Find out and tell me). Comments welcome!

The Servlet lifecycle in detail

When asked about the lifecycle of a servlet 75% of those on whom it is asked to will reply immediately “init, service, destroy”. So, isn’t that right? Yes, it is right, but it does not tell you everything about the servlet lifecycle. And before I had read the HFSJSP even I would have answered the same.

Now, let me tell you elaborately on what leads to a class being called a “servlet” or as it is said in HFSJSP “attaining servletness”. When you look at a class that extends the HttpServlet class you would find that there is nothing special about it. You don’t even find a main() in it. So how does it receive requests from the client and send back response?
As I have shown in the diagram the class that you’ve decided to use as a servlet (by extending HttpServlet/GenericServlet) is just a normal class until either the client sends a request to it or the container decides to load it by itself. All the container has to do to convert the class into a servlet is to create a ServletConfig object for the servlet and pass the reference to it. The creation of the ServletConfig object happens after the default constructor call. Therefore if you ever try to access the ServletConfig of the servlet in the default constructor, all you will ever get is a null.

This is why we are provided with the init() method. Once the ServletConfig is created the container calls the init() method. Now that the ServletConfig is created for the servlet we can get the reference using the getServletConfig() . The ServletConfig could then be used to obtain init parameters (using the getInitParameters() method) that you want to be constant for the servlet through out its life.(I assume that you know how to configure your init parameters in the Deployment Descriptor).

After this, for each request that the servlet receives, the service() method is called which in turn calls the doGet()/doPost… depending on the method of the request sent.

Finally when the container is about to be shut down (redeployed or server is restarted), the destroy() method of the servlet is called. And the servlet is no more.

I hope this helps you :). But make sure you take a look at the books to get a clearer picture of the servlet lifecycle.

Why did I create this?

Well, I can't say 'why' I created this, but maybe I can tell you what led me to start this blog. By looking at the picture beside, you could have by now guessed what really led me to this.I've been preparing for the SCWCD for a few days now. I've never been interested in writing certifications, but I thought that there is no harm in writing one(er.. infact two, I did complete my SCJP but that was because the place I work in asked me to do so).

But Iam not preparing for the certification just for the sake of it, but to gain an in depth knowledge of J2EE.And in the first few days of my preparation I would say that I've learnt a lot of things that I would have never even bothered to learn.So atleast till I complete my certification, almost all of my posts would be related to the SCWCD objectives.

Now, this actually doesn't mean that this blog would help you get a high percentage on your SCWCD. As and when I learn a new thing I would try to put it up here, the way that i've understood it.So most of the content I think would help the novice J2EE guys to get some layman kind of J2EE content.By the way I would like to tell you that Iam using the Head First Servlets & JSP(HFSJ) for my preparation, so don't be surprised if you find things related to the content on the book(but not the content of the book).Let's hope for success!