How HttpSession is not thread safe

[Honey Joshi]

Hi
I have one problem can body tell me how HttpSession is not thread safe. I am refering the HFSJ.
HttpSession creates a unique session id so it creates a uniqueid between the client and the server so it may be a Thread safe.
Please comment i really want the concept of session.

[D Rog]

Session can be invalidated in any moment, so if you obtain a session in one thread, and use synchronized against session in all session consumer threads, a servlet container can invalidate it anyway.

[David O'Meara]

The session object on the server is associated with a single user via the session id passed between them, but there is no guarantee that the user cannot have multiple browser windows using the same session token. You just can't enforce that. Therefore if the user opens the same page in two windows and submits both with same data at the same time, yu may get values from query one, query two, or a mixture of both depending on your treatment of the session object.

Dave

[Prabodh Reddy]

Hi,

in the HFSJ, it mentioned that session attributes are not thread safe.
session attributes are not thread safe in the case when the same user
send multiple requests by opening multiple browsers.in this case
same user multiple requests will hit the service method of the servlet..
so, we have to synchronize code like this

HttpSession session=request.getSession();
synchronize(session)
{
//setAttributes in the session object
//getAttributes from the session object
}

[Honey Joshi]

Originally posted by David O'Meara:
The session object on the server is associated with a single user via the session id passed between them, but there is no guarantee that the user cannot have multiple browser windows using the same session token. You just can't enforce that. Therefore if the user opens the same page in two windows and submits both with same data at the same time, yu may get values from query one, query two, or a mixture of both depending on your treatment of the session object.

Dave

Hi Dave

Container creates a unique session id for the session.

Now the scenario is suppose "XYZ" is a user. Now "XYZ" logins, a new session id is created .
Now again "XYZ" opens the new browser window and again login then i think again a new session id is created.
so it looks like a thread safe if not please explain me.

[David O'Meara]

Not necessarily, it is possible to open a new browser window that has the same session id. Using IE, if you use 'control-N' the new window shares the session id. If however you use the icon to open a new browser, it will get a new session id.

Also keep in mind that browsers are not the only way to access web apps. We could also be talking about a client application that logs in and fires multiple requests on separate threads.

[Anonymous]

david, another possibility of getting the same session is also framed pages being viewed on any browser.

Not at the very first request, but later they will have the same session id and conseq. the same session.

[Honey Joshi]

Originally posted by David O'Meara:
Not necessarily, it is possible to open a new browser window that has the same session id. Using IE, if you use 'control-N' the new window shares the session id. If however you use the icon to open a new browser, it will get a new session id.

Also keep in mind that browsers are not the only way to access web apps. We could also be talking about a client application that logs in and fires multiple requests on separate threads.

Thanks Dave.
Its really a good explaination regarding the browser.
Now understood the concept of Session is not thread safe if the user press ctrl+N then the session is not thread safe otherwise it is thread safe. isn't it.

[Honey Joshi]

Originally posted by Yilmaz Mete:
david, another possibility of getting the same session is also framed pages being viewed on any browser.

Not at the very first request, but later they will have the same session id and conseq. the same session.

Could you please explain the framed page concept related to Session

[David O'Meara]

a framed page has multiple pages nested inside one outer page, but regardless of whether it is nested html pages, images or other resources, the browser may load each part in separate threads. So if each part interacts with the session (imaging that the images etc are all dynamic) and that some of the pages can alter the session, the results returned could depend on the order in which they were loaded.

[Adeel Ansari]

Originally posted by Honey Joshi:
Now understood the concept of Session is not thread safe if the user press ctrl+N then the session is not thread safe otherwise it is thread safe. isn't it.

It was just an example, though. You can take it for sure for IE. And do you remember the other clients which fire request on multiple threads.

Have you ever seen the image, on the registration page or login page or elsewhere, which you have to read and enter the alphabets on image into a text field. That image is to prevent those kind of client's requests. By the way, it might get off-topic. Just remember session attributes are not thread-safe.

[Honey Joshi]

Thanks for solving my problem.

[Honey Joshi]

Originally posted by Adeel Ansari:


It was just an example, though. You can take it for sure for IE. And do you remember the other clients which fire request on multiple threads.

Have you ever seen the image, on the registration page or login page or elsewhere, which you have to read and enter the alphabets on image into a text field. That image is to prevent those kind of client's requests. By the way, it might get off-topic. Just remember session attributes are not thread-safe.

Couldn't understand the description please explain it again.

[Adeel Ansari]

Originally posted by Honey Joshi:
Couldn't understand the description please explain it again.

Ok Honey. Have you ever seen images on a registration form page or on a login page? That image has some alphanumeric values like "hs65tR" or anyother and you need to enter that values, shown on image, into the text field given above, in order to submit the form.

If yes then, you should know why we have to enter that text on the image into the text field. Previously, some bad client programs used to make multiple automatic requests of registration or login, just to give load on the server and until it crashes. Now when you have an image on the form then only a real user can enter that text into that text field, bad client never know what is on the image and what is to enter. They can't just fill fake values in that field like they do for other fields.

Got it?
[ December 22, 2005: Message edited by: Adeel Ansari ]