Hi Stephen, The approach we use was described in my original post. If you need more information then I can explain further if it helps. Note, our approach does require a bespoke tomcat request class (to change the session cookie path) and this has not been without teething problems. Are you also using the window.name to store this unique id? I worry that this may not persist across browser requests in the future but see no other way to identify a browser instance? Ideally the browser vendors should identify somehow on the request a unique id but then again we would still need to support older browser so would have to fall back to the window.name attribute anyway. What fun it is being a web developer and having to deal with the quirks of different browsers and the stateless request/response cycle ;o)
Regards, Rob > > Rob, > > The way you describe session sharing is indeed a problem. The way we deal > with this is to use a separate database table to keep track of window ids. A > unique value is assigned when a window is opened and maintained until the > window is closed. Although the session may be the same for all open windows > (tabs), the window id is unique. Significant values are posted to the window > table and retrieved based on the window id. > > If there is another method using a Tomcat centric approach, I would love to > hear about it. > > Stephen > > On Oct 5, 2010, at 9:01 AM, Ronald Klop wrote: > > > Rob, > > > > IE 6 is even more confusing. If you open a new window with ctrl-N you have > the same session sharing as with tabs. Only if you click the IE6-icon to start > a new instance of the process it will not share them. Opening a new tab in IE7 > is like using ctrl-n to open a new window in IE6. > > > > Ronald. > > > > > > Op dinsdag, 5 oktober 2010 10:26 schreef Rob Gregory > <rob.greg...@ibsolutions.com>: > >> Hi Chris, > >> Is there any way to dynamically create these contexts or do they require a > live.xml, test.xml, etc within conf/Catalina/localhost. The multiple contexts > would be my preferred approach although I would like to achieve this with a > single code base if this is possible. The multiple environments are driven > purely by the backend database connection, i.e. the code is the same with the > only difference being where the data is being saved to. Hence the requirement > to stop the browser sharing the same session when in different database > connections. I'm surprised that other people are not having the same issues > since the browser manufacturers decided to make this crazy change to session > management between tabs/instances and suddenly share the same session. In > I.E.6 two browser instances would be two separate sessions. I.E.7 they are the > same session! Thanks for your input. > >> Kind Regards, > >> Rob. > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> Ronald, > >> On 10/4/2010 6:11 AM, Ronald Klop wrote: > >> > You can run your test environment on another hostname. > >> > > live.example.com > >> > test.example.com > >> > train.example.com > >> Or under another context: > >> http://www.example.com/live > >> http://www.example.com/test > >> http://www.example.com/train > >> The real question is why there's any confusion: your hostnames and/or > >> URLs ought to be unique enough already. Otherwise, this sort of > >> foolishness can affect your "real" users and you'll leak data all over > >> the place. > >> - -chris > >> -----BEGIN PGP SIGNATURE----- > >> Version: GnuPG v1.4.10 (MingW32) > >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > >> iEYEARECAAYFAkyqDDQACgkQ9CaO5/Lv0PDWRACgrlgU+jY+n8nMCZ2WTO63UHDh > >> 10UAoJdyNWqu0nlRGcWbJ6Mcc7zbsGy+ > >> =JP4k > >> -----END PGP SIGNATURE----- > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
