• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Is session object thread safe.

 
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Bartender
Posts: 10336
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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.
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 263
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 208
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 689
Scala Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
No session is not thread safe.

Only request object and local variable are thread safe.. !!
 
carox kaur
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.)
reply
    Bookmark Topic Watch Topic
  • New Topic