The way we have dealt with this (servlets, not EJB) is to add a path extension
to our URL's, c.f.
http://www.mysite.org/zone/servletname/123456789?foo=bar&bash=wibble
This path extension (the 9 digit pseudo-random number) is picked up by our
common platform code, and maps back to an entry in a hashtable attached to the
HttpSession. We call this an application context. A new one of these is
allocated for each interaction sequence, so the windows which are split in this
way quickly end up with different app contexts (in fact, usually immediately,
since the typical behaviour of a user when opening a second window is to begin a
new interaction by clicking on the navbar).
We use BASE HREF in the served pages to ensure relative URLs behave consistently
whether we are using an app context or not.
There is nothing to stop a perverse user from keeping both windows in the same
application and interaction sequence, so we also do a check on any form
transaction from the browser which updates state on the server side, to make
sure we don't accept the same POSTed update twice in a row (also avoids Back
button and click again problems)
We also use it to support applications "calling" each other and returning while
keeping track of a return stack on the server side.
Check out http://www.austinkids.org/site/Donation (this URL will throw a
redirect to a secure server)
Cheers
Dave
Erik Horstkotte wrote:
> I've run into a problem that seems to lie in the borders between Struts
> and Tomcat. We're developing a fairly large JSP & EJB - based project
> and have just run into the fun fact that when a user (of IE 5.5 or
> Communicator 4.61 at least) "splits" the window, the session id cookie
> is inherited by the new window, and therefore *both* windows start
> sharing the same form beans. This causes havoc. I don't see how our app
> can even *detect* the condition, much less *deal* with it.
>
> How are you others out there dealing with this issue?
>
> -- Erik
