ddunkle
asked on
session and IE file->new window
When an IE browser user creates a new browser window with the file->new window menu item, it shares the JSESSIONID cookie with the original window. So they share the same session.
This causes trouble for us, since it is possible to use the session data in incompatible ways in the two windows since the session data is shared. There is a "race condition" between requests made from the two browser windows for shared session data. This is with Tomcat 4.0.x.
For example, say a piece of data valued A, is stored by a request from the first window in the session in an attribute named "sharedVar". Then a request from the second window stores a new value into "sharedVar" with value B. Then a second request from the first window gets "sharedVar" out of the session, expecting value A but gets value B.
We either want a new session created corresponding to each window, to prevent a new window from being created using file->new, or somehow to ensure that each requests from each browser window don't have the race condition.
How can we handle this problem? I would think it would be a common problem, but I can't find anything on it.
thanks,
David
This causes trouble for us, since it is possible to use the session data in incompatible ways in the two windows since the session data is shared. There is a "race condition" between requests made from the two browser windows for shared session data. This is with Tomcat 4.0.x.
For example, say a piece of data valued A, is stored by a request from the first window in the session in an attribute named "sharedVar". Then a request from the second window stores a new value into "sharedVar" with value B. Then a second request from the first window gets "sharedVar" out of the session, expecting value A but gets value B.
We either want a new session created corresponding to each window, to prevent a new window from being created using file->new, or somehow to ensure that each requests from each browser window don't have the race condition.
How can we handle this problem? I would think it would be a common problem, but I can't find anything on it.
thanks,
David
bobbit31
what are you using the session variable for? Maybe there is another approach to what you want to do.
If you click on the IE icon, then the second window will have a new session id.
ASKER
I know that I can click on the IE icon, but I have users who habitually use IE->New Window. Its hard to educate them all; they change too much; there are too many of them.
The session variable is being used to store a current selection of data that is scoped per session. For example, the data organized into divisions. Within each division is a set of teams. The current selected division is saved in the session. With more than one window allowed to operate on the same session, the current division can be set differently by requests from the two windows with a shared session, causing the "race condition" I originally posted. For example, say division A is set by request A from window 1, then, another request from window 1 adds a team to division A. Then a request from window 2 sets current division to division B. Then another request from window 1 trys to add a team to division A (supposedly in the session) but current division is B now, and the team is added to the wrong division.
The session variable is being used to store a current selection of data that is scoped per session. For example, the data organized into divisions. Within each division is a set of teams. The current selected division is saved in the session. With more than one window allowed to operate on the same session, the current division can be set differently by requests from the two windows with a shared session, causing the "race condition" I originally posted. For example, say division A is set by request A from window 1, then, another request from window 1 adds a team to division A. Then a request from window 2 sets current division to division B. Then another request from window 1 trys to add a team to division A (supposedly in the session) but current division is B now, and the team is added to the wrong division.
Unless you can come up with a scheme to accurately identify your windows then I think you'll have to seriously look at not using the session and instead use hidden variables.
ASKER
That is what I think also, but I was hoping that someone else had encountered this before and had a great answer. I am trying to find a way to identify a window now.
if i understand you correctly, you could use a Hashtable in your session...
Hashtable division = new Hashtable();
session.setAttribute("shar
then no matter which window you are in...
Hashtable myData = (Hashtable) session.getAttribute("shar
// if you want to put into divisionA
myData.put("divisionA", <object>);
// if you want to put into divisionB
myData.put("divisionB", <object>);
Hashtable division = new Hashtable();
session.setAttribute("shar
then no matter which window you are in...
Hashtable myData = (Hashtable) session.getAttribute("shar
// if you want to put into divisionA
myData.put("divisionA", <object>);
// if you want to put into divisionB
myData.put("divisionB", <object>);
ASKER
But even with hidden variables, how do you make them unique when a user opens a new browser window with file->new? When I do this in IE, the window gets a copy of the source in the old window including hidden variables.
yes initially the new window is a copy, thats the point. Instead of storing the data in a (shared) session, both windows have their own (private) copy of the data.
ASKER
but whatever hidden variables that are holding state need to be change when the window is copied, but only when the window is copied, not just loaded into an existing window. Right? How do you do that? I am looking at Javascript trying to find a way a hook that tells me when a new window is created, and I don't see a way yet.
I agree that the hashtable method would work.
I agree that the hashtable method would work.
> I agree that the hashtable method would work.
But only if you can identify which window the request is coming from, that is the problem here. If you know what window the request is coming from then in effect you can maintain seperate sessions.
But only if you can identify which window the request is coming from, that is the problem here. If you know what window the request is coming from then in effect you can maintain seperate sessions.
> but whatever hidden variables that are holding state
> need to be change when the window is copied
No you should not need to change the values.
> need to be change when the window is copied
No you should not need to change the values.
> For example, say division A is set by request A from window 1, then, another request from window 1 adds a team to division A. Then a request from window 2 sets current division to division B.
how does window 2 set division to division b after doing the file->new (being that it is a copy of window 1 which is set to division a)? There must be some selection by the user to change it... all i'm saying is to store it as a separate value in the hashtable. wouldn't that work?
how does window 2 set division to division b after doing the file->new (being that it is a copy of window 1 which is set to division a)? There must be some selection by the user to change it... all i'm saying is to store it as a separate value in the hashtable. wouldn't that work?
> There must be some selection by the user to change it.
That's the whole problem, why would the user choose to change it?
That's the whole problem, why would the user choose to change it?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
> I agree that the hashtable method would work.
As well as the problem of identifying the window the request comes from, there is also the problem that if the user invalidates the session in one window (by say logging out) then the hashtable will be lost, invalidating the other session.
ie. you really can't use the session.
As well as the problem of identifying the window the request comes from, there is also the problem that if the user invalidates the session in one window (by say logging out) then the hashtable will be lost, invalidating the other session.
ie. you really can't use the session.
ASKER
I posted 3 new questions to give points to
objects, rrz, and bobbit31. They are (roughly)
this:
points for objects
points for rrz
points for bobbitt
Let me know if you have trouble finding them.
ddunkle
objects, rrz, and bobbit31. They are (roughly)
this:
points for objects
points for rrz
points for bobbitt
Let me know if you have trouble finding them.
ddunkle
ASKER
good cross reference. others get points also.
I thought the x-reference dealt with a different issue. ie. stopping a user have multiple sessions.
> Let me know if you have trouble finding them.
don't see it :( if you tried posting it over the weekend it probably got lost...
don't see it :( if you tried posting it over the weekend it probably got lost...
ASKER
later in the x-ref it talks about this question also.
I think that I will need to implement something like what
they did there in the log run, with modifications to
detect ctrl-N/file->new windows.
what I have done for now is use a hackish trick to "disable"
ctrl-n and file->new, so its really not quite any of these
answers, but its not what I want in the long run either.
I think that I will need to implement something like what
they did there in the log run, with modifications to
detect ctrl-N/file->new windows.
what I have done for now is use a hackish trick to "disable"
ctrl-n and file->new, so its really not quite any of these
answers, but its not what I want in the long run either.
ASKER
bobbit31 I dont know where it went. I tried to repost, but
I mistakenly put it in the wrong area. I am getting it
deleted from the wrong area so I can put it back
I mistakenly put it in the wrong area. I am getting it
deleted from the wrong area so I can put it back
thanks! :)
ASKER
bobbit31 try it now
Just had a thought, one way to get around this problem would be to use URL rewriting instead of cookies.
That way each window could have it's own sessionid.
That way each window could have it's own sessionid.