File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Servlets and the fly likes Session Management Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Servlets
Bookmark "Session Management" Watch "Session Management" New topic

Session Management

saquib nisar

Joined: Nov 13, 2000
Posts: 14
Simple question (I hope).
I hoping to use the HttpSession API to manage session tracking. 2 Questions:
1) Is this suitable for storing a user id, user selections etc.?
2) What is the definition of a session? Is it until the browser is closed, or some time-based concept?
Thanks for you help.
Saquib Nisar
prakash muthu
Ranch Hand

Joined: Sep 06, 2000
Posts: 75
Seesion means life span.
1) you can use it for any one. Its purely based on your request. There is no restrictiopn like you can't use it for username and pwd.
2) Based on the timings the cookies will retain its value. you can set the time for cookies.
Let me know if you need more info.
with regards

Prakash.M<BR>Bangalore- India<BR>(
saquib nisar

Joined: Nov 13, 2000
Posts: 14
Thanks for the response - I am familiar with the time-spans on cookies, but how does this relate to the hhtpsession api?
For example, if I store a user id using the setattribute, how long will this available when I do getattribute? Will it be available until the brower is closed?
Thanks for all repsonses.
ram mohan
Ranch Hand

Joined: Oct 17, 2000
Posts: 68
It is available till either the browser close or the session timeout in the server configuration whichever is lower.
Pls correct me if I am wrong
Sunitha Sounderrajan
Ranch Hand

Joined: Sep 12, 2000
Posts: 36
There is a method in HttpSession called
setMaxInactiveInterval(int interval)
Specifies the time, in seconds, between client requests before the servlet container will invalidate the session.
This relates the session to the httpsession api.
This is my understanding. Someone pls correct if i am wrong.
Sunitha. S
maha anna
Ranch Hand

Joined: Jan 31, 2000
Posts: 1467
HttpSession is like a 'session' you (the browser which in turn really means the user) are having with the Web Application.
The first time you request for some info from the Web Application, the session starts. The session exists normally for 30 min which is normal ,default value comes with all the servlet containers. We can change this value to our wish by
session.setMaxInactiveInterval(int interval) statement.
Having said that, session is used to keep information session-wide, between requests, as persistant values. For example , when the user logs into your application, you may want to set a boolean flag like isLoggedIn = true in session. Which really means from first time the users logs into the system until he/she logs out of the system, (assuming the web appln 'invalidates the session when the user logs out) the boolean value has its persistant value as 'true'.
THis is the whole purpose of session concept. The Http request is stateless. Which means once a httprequest is served, the next request does not know what happend to the previous request or what will happen to the next requsest. We overcome this hurdle by making use of the HttpSession API to keep persistant inforamtion BETWEEN requests like the login case.
As you asked how the .setAttribute("userName",
"saquib nisar") works, what really happens is this.
What the above statement does? This is trying to keep a 'userName' var session-wide var(persistant). How it can be done? The answer is through 'cookies' concept. What really happens is, when the response is sent back to the browser, a a UNIQUE COOKIE named as 'jsessionid' is created with unique value and set in the browser. and ALL OTHER persistant data of this session are kept in the server in some other hashtable machanism.
In other words, in the web application has a global hashtablw which has key-values pairs as 'thisJsessionIdValue' - another Hashtable of ALL session specific info. In this 2nd hashtable only 'userName' - 'saquib nisar' pair is kept in the server and the global table has '1234abcd89' - 'theaddressof2ndHashtable' where '1234abcd80' is the unique value of the 'jSessionid' cookiee which is set in your browser. Do you get the concept ?
So , what happens if the user has turned off the cookies in the browser? Now all the session data gone...? Not necessarily. There is another useful way to take care of these situations. The high level HttpSession API has another way of getting the unique 'jsessiionid' value from the browser apart from cookie concept which I just explained. It is called 'URLRewrting'
'URLRewring' is nothing but 'get the jsessionid from URL itself' kind of (NOT from cookie). What it really means is when you make a request to the web appln you APPEND the extra jsessionid info in the URL itself so that the web application can know which session belongs to this particular user.
We don't do the hard-part of generating the unique URL ourself in our server-side programs. Instead, just wrap-up all the urls which refer to our web application through a special method called 'response.encodeURL(address)'. Rest are all done. This method takes take of generating , and apending the unique sessionID. This is tedious but will work browsers even when the cookies are disabled.
I use this easy and simple way. I wrote a utility method named goToPage like this.

So whenever I redirect/dispatch to a new address from any servlet, I just call this method by giving the appropriate input params. NEED NOT HAND-CODE ALL OVER THE APPLICATION. I find this practice very useful which I found in a hard way , through my experience. 2 months back I wrote a simple authendication webappln and everthing working fine. All of a sudden, the all the session data lost. Nothing worked. Even when I successfully loggedin the appln said 'Go to Login page, you haven't loggedin !'. What really happened was the session data didn't exist. When I contacted the support people, they just said. you have to use encodeURL.
I got a big head-ache of finding all over the places where I refer any url and change to response.encodeURl(..). Latter I made this slightly easier by just calling goToPage, so that it is easy to make the change in only one method and the change of encodind/not-encoding is reflected in WHOLE application.
Also the HttpSession nicely swithes between cookie and urlRewriting method. The default is cookie. If the browser has cookies disabled, then it uses url-rewriting.
You can findout if the current mechanism used is cookie or URL-rewrite by a special API called request.isSessionIdFromCookie (I don't remember the exact name . Please refer to the API). I have used this also.
maha anna
ray bond
Ranch Hand

Joined: Oct 11, 2000
Posts: 111
how can you check in your servlet code that enduser's browser accepts cookies or not , so you can decide which method to use for session tracking ???
maha anna
Ranch Hand

Joined: Jan 31, 2000
Posts: 1467
There is an API to check if the sessionID came from cookie or not.
I grabbed this code snippet from 'Marty Hall' book Save this as test.jsp and try to call this jsp through browser with/without cookies enabled in the browser.
It will print true when the browser's cookie is enabled and false when not. Actually we neednot take this decision of checking if the browser supports cookie or not and take action accordingly. If we write our code with Url-rewriting method, the decision of getting the sessionId from cookie / url is automatically taken care of. The default is cookie concept. So if the browser supports cookies , wrapping an address with encodeURL(...) method does not change the returned url. OTherwise, the method appends the returned url with ;jsessionid=***** string.
So the bottomline is if an application depends on cookies only , it may not work all the time. On the other hand if you write with the elaborate url-rewriting it will definitly work in both cases.

maha anna
[This message has been edited by maha anna (edited November 21, 2000).]
I agree. Here's the link:
subject: Session Management
It's not a secret anymore!