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 PROTECTED]
