How to avoid session sharing provided by IE8 programmatically in Java EE application?

Question

Microsoft, in an effort to make Internet Explorer 8 "more stable" and “faster”, have changed the underlying architecture of the browser and introduced a function called "Loosely-Coupled IE" (LCIE) which works on session sharing across TAB and new instances.

But session sharing may be fatal when some one is trying to do two different things at a time with the same application, e.g. like someone want to book one forward journey ticket and one return ticket at a time, at that time he will book 2 same tickets what he has not intended to.

PROBABLE SOLUTION ON IT

1. While creating a new window instead of creating by clicking on an icon or Ctrl+N, we should use File -> New Session; it will not happen.

2. You can make a registry change on the client PC - adding the following.

   [HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main]

“TabProcGrowth" = dword : 00000000

Will disable "Loosely Couple IE8"; IE8 then works as previous versions of IE.

3. Run MSIE using iexplore.exe -nomerge will disable "Loosely Couple IE8"; IE8 then works as previous versions of IE.

But how will I do it programatically?

---

You see, my problem is not my application. It's working fine if I am logging in one user, but when I am logging in multiple users through different users from different instances of IE8 browser, my later session data are overriding the former one, this is because both the IE browsers are using the same session id. It's happening because of session sharing of IE8. There is only one session maintained for one application however how many users I am logging in. In fact I want to mantain on session per user.

Like when I am logging in Gmail in one browser. If I am just typing Gmail on another browser. It's logging in automatically. I don't want this in my application. I should get login by another user at a time I should perform independent operation.

My application uses Struts, Spring, Hibernate & JBoss application server.

Now tell me how I should proceed?

Answer 1

I think the issues you describe above can be replicated on all browsers and can be better tackled server side. One approach I know of is to create a conversation id and manage the lifecycle of the conversation with a statemachine.

This allows you (and your users) to have one sesion where multiple conversations can be held concurently, which happens a lot in practice, well, at least in internal enterprise applications. The world is a more chaotic place than the business process models let show.