Re: Struts and the infamous IE multiple browser/same session problem
Michael Ruppin wrote: I'm reconsidering my approach to this problem, in favor of something more elegant/more compatible with out-of-the-box Struts. Anyone tackled this yet? For those not aware, MS IE allows users to launch a browser against the same session via File/New/Window (Ctrl-N). The issue is, if you have need to keep data in the session (which I do), a submission from one browser could grab and/or overwrite session data meant for the other browser. This can lead to data integrity problems and other weirdness. Telling my user community not to use MS IE or it's Ctrl-N feature is not an option. My current approach is to put a hidden random key into the HTML, and name the session attribute with that. When one of the two browsers submits a request (Assuming, at this point, they've opened another) the session data is pulled by key, assigned a new key, a new copy is placed in the session named with the new key, and the new key is rendered in the HTML response. The old session data may or may not be removed, depending on whether or not it is acceptable for the browser with the old key to [gracefully] fail, how we choose to expire session data, and whether or not a means of dealing with stale data is supported by the model. This works fine, but in doing so I've had to write my own methods for populating collections of forms which would have otherwise been taken care of for me by specifying session scope in struts-config. Am I missing a better way? m Out of curiosity, what kind of application do you have where you really *need* to support someone having multiple different sessions active at the same time? I'm not necessarily saying that you don't need this - I'm just wondering. You may be bending over backwards to solve a problem that real users (as opposed to testers) won't have. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts and the infamous IE multiple browser/same session problem
I guess you could say, An application where those footing the bill (Client) demand it. But, it's not application specific, and it's not multiple sessions we're talking about here, it's multiple browsers on the same session. Multiple sessions are a non-issue. Regardless of what your application is, one of the following should be true: 1) You do nothing about multiple browsers on the same session, and a) You use no session data b) You take your chances that session data may become corrupt 2) You prevent multiple browsers on the same session through a) JavaScript (Risky, since it could be turned off) b) Synchronized Tokens? 3) You do something to segregate the session data between browsers. 1b is not acceptable to most Clients since their data is at risk, and when it is acceptable, you still take the chance that you may have corrupted data to fix. 2 is acceptable for most Clients, data integrity tends to be a higher priority than keeping the end user happy. When, however, the Client insists on data integrity and optimal ease of use, you're left to implement 1a or 3. [OT] If your real question was what Under what circumstances would a user want more than one browser accessing a given application, regardless of whether or not they have the same session, the answers are many. How about a warehouse application where the Customer Service Representatives need to see Orders, Inventory, and Customer data, at the same time? Its not always acceptable to anticipate what combinations of data they need to see at the same time, and can it into a screen. Nor is it acceptable to tell them they have to keep navigating from one to another constantly. The answer is, they want multiple browsers viewing whatever datum is of interest to them at the moment. m --- Doug [EMAIL PROTECTED] wrote: Michael Ruppin wrote: I'm reconsidering my approach to this problem, in favor of something more elegant/more compatible with out-of-the-box Struts. Anyone tackled this yet? For those not aware, MS IE allows users to launch a browser against the same session via File/New/Window (Ctrl-N). The issue is, if you have need to keep data in the session (which I do), a submission from one browser could grab and/or overwrite session data meant for the other browser. This can lead to data integrity problems and other weirdness. Telling my user community not to use MS IE or it's Ctrl-N feature is not an option. My current approach is to put a hidden random key into the HTML, and name the session attribute with that. When one of the two browsers submits a request (Assuming, at this point, they've opened another) the session data is pulled by key, assigned a new key, a new copy is placed in the session named with the new key, and the new key is rendered in the HTML response. The old session data may or may not be removed, depending on whether or not it is acceptable for the browser with the old key to [gracefully] fail, how we choose to expire session data, and whether or not a means of dealing with stale data is supported by the model. This works fine, but in doing so I've had to write my own methods for populating collections of forms which would have otherwise been taken care of for me by specifying session scope in struts-config. Am I missing a better way? m Out of curiosity, what kind of application do you have where you really *need* to support someone having multiple different sessions active at the same time? I'm not necessarily saying that you don't need this - I'm just wondering. You may be bending over backwards to solve a problem that real users (as opposed to testers) won't have. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts and the infamous IE multiple browser/same session problem
I guess you could say, An application where those footing the bill (Client) demand it. But, it's not application specific, and it's not multiple sessions we're talking about here, it's multiple browsers on the same session. Multiple sessions are a non-issue. Regardless of what your application is, one of the following should be true: 1) You do nothing about multiple browsers on the same session, and a) You use no session data b) You take your chances that session data may become corrupt 2) You prevent multiple browsers on the same session through a) JavaScript (Risky, since it could be turned off) b) Synchronized Tokens? 3) You do something to segregate the session data between browsers. 4) you configure MSIE not to open new browsers on the same session. This works, if the application is being used within a corporate (Intranet) envinronment. -TPP - This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Also, email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts and the infamous IE multiple browser/same session problem
4) you configure MSIE not to open new browsers on the same session. This works, if the application is being used within a corporate (Intranet) envinronment. How do you confiure MSIE to not open a new window in the same session ? -Original Message- From: Paananen, Tero [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 1:08 PM To: 'Struts Users Mailing List' Subject: RE: Struts and the infamous IE multiple browser/same session problem I guess you could say, An application where those footing the bill (Client) demand it. But, it's not application specific, and it's not multiple sessions we're talking about here, it's multiple browsers on the same session. Multiple sessions are a non-issue. Regardless of what your application is, one of the following should be true: 1) You do nothing about multiple browsers on the same session, and a) You use no session data b) You take your chances that session data may become corrupt 2) You prevent multiple browsers on the same session through a) JavaScript (Risky, since it could be turned off) b) Synchronized Tokens? 3) You do something to segregate the session data between browsers. 4) you configure MSIE not to open new browsers on the same session. This works, if the application is being used within a corporate (Intranet) envinronment. -TPP - This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Also, email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts and the infamous IE multiple browser/same session problem
You can't. You can (I gather) prevent CTRL-N opening a new window automatically, but there's nothing stopping the user from opening a new browser instance manually. You still get the same session. Steve -Original Message- From: Geoff Apps [mailto:[EMAIL PROTECTED] Sent: May 30, 2003 7:16 AM To: Struts Users Mailing List Subject: RE: Struts and the infamous IE multiple browser/same session problem 4) you configure MSIE not to open new browsers on the same session. This works, if the application is being used within a corporate (Intranet) envinronment. How do you confiure MSIE to not open a new window in the same session ? -Original Message- From: Paananen, Tero [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2003 1:08 PM To: 'Struts Users Mailing List' Subject: RE: Struts and the infamous IE multiple browser/same session problem 4) you configure MSIE not to open new browsers on the same session. This works, if the application is being used within a corporate (Intranet) envinronment. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts and the infamous IE multiple browser/same session problem
4) you configure MSIE not to open new browsers on the same session. This works, if the application is being used within a corporate (Intranet) envinronment. How do you confiure MSIE to not open a new window in the same session ? There used to be an option on older MSIE versions that let you set that (Tools - Internet Options - Advanced - Browsing) Microsoft removed that option in version 5, and it's not there any more. Microsoft thought it'd be a great idea to remove it, because they know better: http://support.microsoft.com/support/kb/articles/q240/9/28.asp You can, however, still get MSIE do that, if you hack the registry a little bit and then enable the option in MSIE, as described in the following Usenet post: http://groups.google.com/groups?selm=uIfwOsFs%24GA.213%40cppssbbsa03 -TPP - This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Also, email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts and the infamous IE multiple browser/same session problem
This post is worth a read if you're concerned about thread safety and ActionForms: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] he.orgmsgNo=37535 Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Struts and the infamous IE multiple browser/same session problem
I'm reconsidering my approach to this problem, in favor of something more elegant/more compatible with out-of-the-box Struts. Anyone tackled this yet? For those not aware, MS IE allows users to launch a browser against the same session via File/New/Window (Ctrl-N). The issue is, if you have need to keep data in the session (which I do), a submission from one browser could grab and/or overwrite session data meant for the other browser. This can lead to data integrity problems and other weirdness. Telling my user community not to use MS IE or it's Ctrl-N feature is not an option. My current approach is to put a hidden random key into the HTML, and name the session attribute with that. When one of the two browsers submits a request (Assuming, at this point, they've opened another) the session data is pulled by key, assigned a new key, a new copy is placed in the session named with the new key, and the new key is rendered in the HTML response. The old session data may or may not be removed, depending on whether or not it is acceptable for the browser with the old key to [gracefully] fail, how we choose to expire session data, and whether or not a means of dealing with stale data is supported by the model. This works fine, but in doing so I've had to write my own methods for populating collections of forms which would have otherwise been taken care of for me by specifying session scope in struts-config. Am I missing a better way? m __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts and the infamous IE multiple browser/same session problem
have you considered creating a unique token to do session related updates? i don't think tokens can be transferred from one browser window to another though i could be wrong. -Original Message- From: Michael Ruppin [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 28, 2003 3:47 PM To: Struts Users Mailing List Subject: Struts and the infamous IE multiple browser/same session problem I'm reconsidering my approach to this problem, in favor of something more elegant/more compatible with out-of-the-box Struts. Anyone tackled this yet? For those not aware, MS IE allows users to launch a browser against the same session via File/New/Window (Ctrl-N). The issue is, if you have need to keep data in the session (which I do), a submission from one browser could grab and/or overwrite session data meant for the other browser. This can lead to data integrity problems and other weirdness. Telling my user community not to use MS IE or it's Ctrl-N feature is not an option. My current approach is to put a hidden random key into the HTML, and name the session attribute with that. When one of the two browsers submits a request (Assuming, at this point, they've opened another) the session data is pulled by key, assigned a new key, a new copy is placed in the session named with the new key, and the new key is rendered in the HTML response. The old session data may or may not be removed, depending on whether or not it is acceptable for the browser with the old key to [gracefully] fail, how we choose to expire session data, and whether or not a means of dealing with stale data is supported by the model. This works fine, but in doing so I've had to write my own methods for populating collections of forms which would have otherwise been taken care of for me by specifying session scope in struts-config. Am I missing a better way? m __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts and the infamous IE multiple browser/same session problem
Everyone's favorite!!! ;)
you can always disable control-N via JavaScript ;)
in an onkeydown handler probably for a body tag.
//check for control n
if (window.event.ctrlKey window.event.keyCode == 78)
{
window.event.returnValue = false;
return false;
}
--m
-Original Message-
From: Pani, Gourav [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 28, 2003 3:50 PM
To: 'Struts Users Mailing List'
Subject: RE: Struts and the infamous IE multiple browser/same session
problem
have you considered creating a unique token to do session related updates?
i don't think tokens can be transferred from one browser window to another
though i could be wrong.
-Original Message-
From: Michael Ruppin [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 28, 2003 3:47 PM
To: Struts Users Mailing List
Subject: Struts and the infamous IE multiple browser/same session
problem
I'm reconsidering my approach to this problem, in
favor of something more elegant/more compatible with
out-of-the-box Struts. Anyone tackled this yet?
For those not aware, MS IE allows users to launch a
browser against the same session via File/New/Window
(Ctrl-N). The issue is, if you have need to keep data
in the session (which I do), a submission from one
browser could grab and/or overwrite session data meant
for the other browser. This can lead to data
integrity problems and other weirdness. Telling my
user community not to use MS IE or it's Ctrl-N feature
is not an option.
My current approach is to put a hidden random key
into the HTML, and name the session attribute with
that. When one of the two browsers submits a request
(Assuming, at this point, they've opened another) the
session data is pulled by key, assigned a new key, a
new copy is placed in the session named with the new
key, and the new key is rendered in the HTML
response. The old session data may or may not be
removed, depending on whether or not it is acceptable
for the browser with the old key to [gracefully] fail,
how we choose to expire session data, and whether or
not a means of dealing with stale data is supported by
the model.
This works fine, but in doing so I've had to write my
own methods for populating collections of forms which
would have otherwise been taken care of for me by
specifying session scope in struts-config. Am I
missing a better way?
m
__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts and the infamous IE multiple browser/same session problem
I'm reconsidering my approach to this problem, in favor of something more elegant/more compatible with out-of-the-box Struts. Anyone tackled this yet? Wait till you find out that MSIE, in its default configuration, will happily cache even dynamicly generated pages, so your token key approach will break just as easily. -TPP - oxymoron of the day: Microsoft standards - This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Also, email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts and the infamous IE multiple browser/same session problem
Mike Thompson wrote:
Everyone's favorite!!! ;)
you can always disable control-N via JavaScript ;)
in an onkeydown handler probably for a body tag.
//check for control n
if (window.event.ctrlKey window.event.keyCode == 78)
{
window.event.returnValue = false;
return false;
}
And people wonder why some folks disable JavaScript.
;)
Erik
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts and the infamous IE multiple browser/same session problem
Thanks, but I should have mentioned, no JavaScript
allowed here. At least not for something this mission
critical.
m
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=73921
--- Mike Thompson [EMAIL PROTECTED] wrote:
Everyone's favorite!!! ;)
you can always disable control-N via JavaScript ;)
in an onkeydown handler probably for a body tag.
//check for control n
if (window.event.ctrlKey window.event.keyCode
== 78)
{
window.event.returnValue = false;
return false;
}
--m
-Original Message-
From: Pani, Gourav
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 28, 2003 3:50 PM
To: 'Struts Users Mailing List'
Subject: RE: Struts and the infamous IE multiple
browser/same session
problem
have you considered creating a unique token to do
session related updates?
i don't think tokens can be transferred from one
browser window to another
though i could be wrong.
-Original Message-
From: Michael Ruppin [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 28, 2003 3:47 PM
To: Struts Users Mailing List
Subject: Struts and the infamous IE multiple
browser/same session
problem
I'm reconsidering my approach to this problem, in
favor of something more elegant/more compatible with
out-of-the-box Struts. Anyone tackled this yet?
For those not aware, MS IE allows users to launch a
browser against the same session via File/New/Window
(Ctrl-N). The issue is, if you have need to keep
data
in the session (which I do), a submission from one
browser could grab and/or overwrite session data
meant
for the other browser. This can lead to data
integrity problems and other weirdness. Telling my
user community not to use MS IE or it's Ctrl-N
feature
is not an option.
My current approach is to put a hidden random key
into the HTML, and name the session attribute with
that. When one of the two browsers submits a
request
(Assuming, at this point, they've opened another)
the
session data is pulled by key, assigned a new key, a
new copy is placed in the session named with the new
key, and the new key is rendered in the HTML
response. The old session data may or may not be
removed, depending on whether or not it is
acceptable
for the browser with the old key to [gracefully]
fail,
how we choose to expire session data, and whether or
not a means of dealing with stale data is supported
by
the model.
This works fine, but in doing so I've had to write
my
own methods for populating collections of forms
which
would have otherwise been taken care of for me by
specifying session scope in struts-config. Am I
missing a better way?
m
__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to
Outlook(TM).
http://calendar.yahoo.com
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts and the infamous IE multiple browser/same session problem
I'm not sure if this is a response to me, or to Gourav Pani. As far as my current solution goes, I don't see how _any_ caching by the client can break it. Depending on the level of support chosen for this, if the client submits a form with an old key, the important data in the session has either a) Been removed from the session by the server, causing the jsp to render HTML with no data. or b) Contains a version originating from the model (crude but effective?). Presuming the submission from the first browser actually changed the model data, the version number will have changed such that if this old session data is passed to the model it responds with Stale Data. I'm still unhappy with my solution though, since I waste a lot of time explaining it to my team, and potentially to new developers. m --- Paananen, Tero [EMAIL PROTECTED] wrote: I'm reconsidering my approach to this problem, in favor of something more elegant/more compatible with out-of-the-box Struts. Anyone tackled this yet? Wait till you find out that MSIE, in its default configuration, will happily cache even dynamicly generated pages, so your token key approach will break just as easily. -TPP - oxymoron of the day: Microsoft standards - This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Also, email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts and the infamous IE multiple browser/same session problem
Forgive me if I'm misunderstanding something here because I am unaware of the background and previous discussions on this topic. This doesn't seem to just be a issue with IE. Mozilla and Opera both keep the same session if you have multiple browser windows open. It doesn't matter whether you open a new window in a separate tab or browser, it still maintains the same session. Why would you even want a browser that enforced separate sessions if you open a new window. I may want to accomplish several tasks or refer to information while I'm updating something else. There are any number of reasons why I would want multiple windows. If you enforced separate sessions then I would have to login each time I opened a window. Not exactly convenient for the user! Why is this considered a problem? The session represents the state for the user, not for a particular browser window. Each window is just a view of the model so it should not matter how many different views are active at any time. If you need to guard against inconsistent data then you need to be aware that the session is not thread safe and ensure that you do your own synchronization on any objects that you place in it. Surely, this is no more a bug than the database bug where data gets out of sync when you don't use transactions? ;-) Anyway, to avoid any problems here's a few options: 1. Synchronize objects that you use in the session 2. Don't use the session at all. Store your 'session' information in a database. Some distributed session managers do this for you. 3. Synchronize on some other session 'locking' object if you need to update multiple session objects in a transaction. 4. Consider using an optimistic locking system for your session objects. Add a version number property to the objects you're going to place in the session. Check it for each update request and reject the update if the session numbers don't match. (You'll still need to synchronize for updates but not for reads). Don't shoot me if the last option doesn't work. It just occurred to me while I was thing about database transactions :-) Like I said, if I've misunderstood then please (gently) point out of the error of my ways. Steve -Original Message- From: Michael Ruppin [mailto:[EMAIL PROTECTED] Sent: May 28, 2003 1:47 PM To: Struts Users Mailing List Subject: Struts and the infamous IE multiple browser/same session problem I'm reconsidering my approach to this problem, in favor of something more elegant/more compatible with out-of-the-box Struts. Anyone tackled this yet? For those not aware, MS IE allows users to launch a browser against the same session via File/New/Window (Ctrl-N). The issue is, if you have need to keep data in the session (which I do), a submission from one browser could grab and/or overwrite session data meant for the other browser. This can lead to data integrity problems and other weirdness. Telling my user community not to use MS IE or it's Ctrl-N feature is not an option. My current approach is to put a hidden random key into the HTML, and name the session attribute with that. When one of the two browsers submits a request (Assuming, at this point, they've opened another) the session data is pulled by key, assigned a new key, a new copy is placed in the session named with the new key, and the new key is rendered in the HTML response. The old session data may or may not be removed, depending on whether or not it is acceptable for the browser with the old key to [gracefully] fail, how we choose to expire session data, and whether or not a means of dealing with stale data is supported by the model. This works fine, but in doing so I've had to write my own methods for populating collections of forms which would have otherwise been taken care of for me by specifying session scope in struts-config. Am I missing a better way? m __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts and the infamous IE multiple browser/same session problem
Another fun thing to consider with multiple browser windows is the problems you get if multiple windows are showing the same edit page (ie: same action) , but editing different records, and you are using a session scoped actionForm... -Original Message- From: Steve Raeburn [mailto:[EMAIL PROTECTED] Sent: Thursday, 29 May 2003 06:52 To: Struts Users Mailing List Subject: RE: Struts and the infamous IE multiple browser/same session problem Forgive me if I'm misunderstanding something here because I am unaware of the background and previous discussions on this topic. This doesn't seem to just be a issue with IE. Mozilla and Opera both keep the same session if you have multiple browser windows open. It doesn't matter whether you open a new window in a separate tab or browser, it still maintains the same session. Why would you even want a browser that enforced separate sessions if you open a new window. I may want to accomplish several tasks or refer to information while I'm updating something else. There are any number of reasons why I would want multiple windows. If you enforced separate sessions then I would have to login each time I opened a window. Not exactly convenient for the user! Why is this considered a problem? The session represents the state for the user, not for a particular browser window. Each window is just a view of the model so it should not matter how many different views are active at any time. If you need to guard against inconsistent data then you need to be aware that the session is not thread safe and ensure that you do your own synchronization on any objects that you place in it. Surely, this is no more a bug than the database bug where data gets out of sync when you don't use transactions? ;-) Anyway, to avoid any problems here's a few options: 1. Synchronize objects that you use in the session 2. Don't use the session at all. Store your 'session' information in a database. Some distributed session managers do this for you. 3. Synchronize on some other session 'locking' object if you need to update multiple session objects in a transaction. 4. Consider using an optimistic locking system for your session objects. Add a version number property to the objects you're going to place in the session. Check it for each update request and reject the update if the session numbers don't match. (You'll still need to synchronize for updates but not for reads). Don't shoot me if the last option doesn't work. It just occurred to me while I was thing about database transactions :-) Like I said, if I've misunderstood then please (gently) point out of the error of my ways. Steve -Original Message- From: Michael Ruppin [mailto:[EMAIL PROTECTED] Sent: May 28, 2003 1:47 PM To: Struts Users Mailing List Subject: Struts and the infamous IE multiple browser/same session problem I'm reconsidering my approach to this problem, in favor of something more elegant/more compatible with out-of-the-box Struts. Anyone tackled this yet? For those not aware, MS IE allows users to launch a browser against the same session via File/New/Window (Ctrl-N). The issue is, if you have need to keep data in the session (which I do), a submission from one browser could grab and/or overwrite session data meant for the other browser. This can lead to data integrity problems and other weirdness. Telling my user community not to use MS IE or it's Ctrl-N feature is not an option. My current approach is to put a hidden random key into the HTML, and name the session attribute with that. When one of the two browsers submits a request (Assuming, at this point, they've opened another) the session data is pulled by key, assigned a new key, a new copy is placed in the session named with the new key, and the new key is rendered in the HTML response. The old session data may or may not be removed, depending on whether or not it is acceptable for the browser with the old key to [gracefully] fail, how we choose to expire session data, and whether or not a means of dealing with stale data is supported by the model. This works fine, but in doing so I've had to write my own methods for populating collections of forms which would have otherwise been taken care of for me by specifying session scope in struts-config. Am I missing a better way? m __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
RE: Struts and the infamous IE multiple browser/same session problem
Well, I'm not sure exactly how to implement your solutions 1 and 3. Perhaps 1 is what I am doing? 2 might be nice, but it's not considered good to hit the model on every submission, and theres more to persist than just the model. For 4, when you say Check it for each update request and reject the update if the session numbers don't match, I assume you mean reject the update if the *version* numbers don't match. The problems with this are scenarios like the following: Browsers 1 2 are on the same session, with version 1 of a form object with property Checkbox=false. Checkbox is not part of the model. Let's assume the form is session scoped. Browser 1 checks the checkbox and submits a Delete checked request. This navigates them to a confirmation screen. Meanwhile, browser 2 submits something like Refresh. Struts calls the reset method on this form, where, of course, I default Checked=false. Browser 1 now submits OK, to confirm the delete. The delete method finds the forms checkbox unchecked, and does nothing. This situation is not so bad, but there are many others which may be. I do a lot of nested indexed forms. It may actually be good, if one form refreshes the session data from the model for another, but is it appropriate for one browser to entirely alter the list of another, or its non-model components? This will cause a lot of confusion, at minimum. My solution is to name the session data based a number unique to each browser. The version is still implemented, to cover the DB issues. The problem with this solution is, I have to do a lot of the work Struts would normally do for me, myself. Based on posts Ive read concerning disabling a browsers Back button, it sounds like I might be able to make use of Action token methods to prevent duplicate submissions. However, as you say, enforcing that each browser has its own session is not convenient for the user, and some clients insist that we support the multiple browser / same session scenario. Other ideas, anyone? m m --- Steve Raeburn [EMAIL PROTECTED] wrote: Forgive me if I'm misunderstanding something here because I am unaware of the background and previous discussions on this topic. This doesn't seem to just be a issue with IE. Mozilla and Opera both keep the same session if you have multiple browser windows open. It doesn't matter whether you open a new window in a separate tab or browser, it still maintains the same session. Why would you even want a browser that enforced separate sessions if you open a new window. I may want to accomplish several tasks or refer to information while I'm updating something else. There are any number of reasons why I would want multiple windows. If you enforced separate sessions then I would have to login each time I opened a window. Not exactly convenient for the user! Why is this considered a problem? The session represents the state for the user, not for a particular browser window. Each window is just a view of the model so it should not matter how many different views are active at any time. If you need to guard against inconsistent data then you need to be aware that the session is not thread safe and ensure that you do your own synchronization on any objects that you place in it. Surely, this is no more a bug than the database bug where data gets out of sync when you don't use transactions? ;-) Anyway, to avoid any problems here's a few options: 1. Synchronize objects that you use in the session 2. Don't use the session at all. Store your 'session' information in a database. Some distributed session managers do this for you. 3. Synchronize on some other session 'locking' object if you need to update multiple session objects in a transaction. 4. Consider using an optimistic locking system for your session objects. Add a version number property to the objects you're going to place in the session. Check it for each update request and reject the update if the session numbers don't match. (You'll still need to synchronize for updates but not for reads). Don't shoot me if the last option doesn't work. It just occurred to me while I was thing about database transactions :-) Like I said, if I've misunderstood then please (gently) point out of the error of my ways. Steve -Original Message- From: Michael Ruppin [mailto:[EMAIL PROTECTED] Sent: May 28, 2003 1:47 PM To: Struts Users Mailing List Subject: Struts and the infamous IE multiple browser/same session problem I'm reconsidering my approach to this problem, in favor of something more elegant/more compatible with out-of-the-box Struts. Anyone tackled this yet? For those not aware, MS IE allows users to launch a browser against the same session via File/New/Window (Ctrl-N). The issue is, if you have need to keep data in the session (which I do), a submission from one browser could grab
