aspose file tools*
The moose likes Servlets and the fly likes Is session object thread safe. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Servlets
Bookmark "Is session object thread safe." Watch "Is session object thread safe." New topic
Author

Is session object thread safe.

carox kaur
Ranch Hand

Joined: Mar 19, 2009
Posts: 52
I know how the state of a user is managed through session (instance of HttpSession interface). The conatiner maintains a pool of session objects and a map which maps the reference of session objects with a unique ID. When the user sends the request first time, then container calls the getSession() on the request object, the container tries to get Session cookie which contains the unique sessionID. If it finds any cookie, then the session ID in it is mapped with the references of session objects. If the match is not found or no cookie is found in the request object then a new session object is created/picked from the pool and is associated with a unique sessionId, these are thereafter maintained in the map. This sessionID is embedded in the cookie and is send to the user through response object. But if match is found then the session object is choosen and is associated with the client.

How does the container uniquely identify the users? Through unique sessionID which is send in the form of cookie to the server with the request. I hope I am right till here. What happens if I open two browers from the same machine and send the request? Will both the browers will send the same sessionID? Is the sessionID composed of BrowerID + client host ID?
According to me, this question will determine whether the session objects are thread safe.
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336


Will both the browers will send the same sessionID?

No.

You only need to worry about the multi threaded behaviour of the HTTPSession if you have two threads accessing the same session attribute from the same browser instance. In normal web applications this should never happen. Where you need to be concerned is if you use AJAX.


JavaRanch FAQ HowToAskQuestionsOnJavaRanch
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42612
    
  65
If you use two different browsers (like IE and Firefox), then you will end up with two different sessions. If you open the same web app twice from within the same browser, then it depends a bit on how you open the second instance, and which browser you're using - you may or may not end up using the same session.

According to me, this question will determine whether the session objects are thread safe.

Even if the session object is thread-safe, that doesn't imply that all objects you access through it (like session attributes) are thread-safe; as a matter of fact, they're not. If your code is supposed to be thread-safe (and in a multi-threaded environment like a servlet container you had better make sure that it is) then you need to code in a way that it's safe to use session attributes concurrently.


Ping & DNS - my free Android networking tools app
James Ward
Ranch Hand

Joined: Apr 27, 2003
Posts: 263
1. Two different Browsers (IE, FireFox) - they will not use the same cookie, it will result in two different sessions.

2. Same Browser(IE) - will result in a new session or not(i.e will share cookies or not), depending on how the second browser instance was opened. In case of IE, if you open a new browser instance by hitting hit ctrl-N, ctrl-T(new tab); the second browser instance will share cookies/sessions etc. But if you go via Program Files > IE, then the second browser instance will result in new sessions/cookies.

Hope this helps.
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12823
    
    5
Important note:

It is entirely possible for a browser to fire off multiple requests which will be processed "at the same time" so there will be multiple requests using the same session object. Therefore you should think carefully before assuming your session "is thread safe."

Bill
shukla raghav
Ranch Hand

Joined: Aug 03, 2008
Posts: 200
well it is not thread safe :

imagine a user opens two windows from the same client and sends a delete request from one and insert from the other at nearly the same time. may result in inconsistent data
Nishan Patel
Ranch Hand

Joined: Sep 07, 2008
Posts: 689

No session is not thread safe.

Only request object and local variable are thread safe.. !!


Thanks, Nishan Patel
SCJP 1.5, SCWCD 1.5, OCPJWSD Java Developer,My Blog
carox kaur
Ranch Hand

Joined: Mar 19, 2009
Posts: 52
Same Browser(IE) - will result in a new session or not(i.e will share cookies or not), depending on how the second browser instance was opened. In case of IE, if you open a new browser instance by hitting hit ctrl-N, ctrl-T(new tab); the second browser instance will share cookies/sessions etc. But if you go via Program Files > IE, then the second browser instance will result in new sessions/cookies.

Thanks this helps but I have not understood many things.....

imagine a user opens two windows from the same client and sends a delete request from one and insert from the other at nearly the same time. may result in inconsistent data

If two windows are opened from the same client, then what you are saying is true ONLY IF we open the windows using ctrl-N, ctrl-T (new Tab) as these two browsers will share the sessionId (cookie). Are you assuming these? Do we have to consider this particular thing also. Else how the two windows will share the same cookie?

there will be multiple requests using the same session object.

I am trying to find this only, how multiple requests can share the same session object? This is possible only if all the requests sends/shares the same cookie. Again this depends on how the browsers are opened.

Even if the session object is thread-safe, that doesn't imply that all objects you access through it (like session attributes) are thread-safe; as a matter of fact, they're not

How? If the session object is thread safe, then this means that the object will be accessible to only one thread at a time, true? If this object is accessible to only one thread at a time, then only one thread will be able to make updations in the attributes in it at a time.

You only need to worry about the multi threaded behaviour of the HTTPSession if you have two threads accessing the same session attribute from the same browser instance. In normal web applications this should never happen

So this means that session objects are thread safe? As two threads cannot send request from same browser instance, unlesss the browser is opened using ctrl-N, ctrl-T?

In HeadFirst book its written that the session objects are not thread safe. The book says "The client could open a new browser window and so the container can still use the same session for the client, even though its coming from a different instance of the browser. So session attributes are not thread safe." Here also this is true if the second browser is opened as a tab or through new window.
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42612
    
  65
carox kaur wrote:
Ulf Dittmer wrote:Even if the session object is thread-safe, that doesn't imply that all objects you access through it (like session attributes) are thread-safe; as a matter of fact, they're not

How? If the session object is thread safe, then this means that the object will be accessible to only one thread at a time, true?

No. It means that the object can safely be called by multiple requests. The circumstances under which this can happen are discussed in several of the posts above.

If this object is accessible to only one thread at a time, then only one thread will be able to make updations in the attributes in it at a time.

Since it *IS* accessible to multiple threads, multiple threads can access and update session attributes simultaneously. The developer must ensure that all such access is thread-safe (through proper use of locks, synchronization etc.)
 
Don't get me started about those stupid light bulbs.
 
subject: Is session object thread safe.