We have a report that shows many rows of data together with a link to drill down on a particular row by branching to another page, passing the row PK as a parameter - standard stuff.

However, some of our users like to use the browser facility to open the link in a new window. They then go back to the report and maybe open another link in another new window.

Now they have 2 new windows open, supposedly showing 2 different sets of data. But since the windows share the same SESSION value, the session state gets mixed up. If they click the 2 links quickly enough they can even end up with the same data displayed in both windows.

I realise that I can avoid this by NOT passing the session ID. But since the user could do this with any link, that means NEVER passing the session ID in any link, so effectively not having any persistent session state.

Is it possible to:
- prevent the user from opening the link in a new window?
- recognize that the user has opened the link in a new window and start a new session?

This must be a potential issue for all ApEx applications, so I am sure someone has solved it already!

The problem happens when users deliberately open multiple windows off links, all in the same AppEx session, e.g., using IE's CTRL+N. Pages that alter session state during rendering can step on each other. There is no ready solution to this now, but we're thinking about it.

Scott

Another way users can end up with the same session in 2 browser windows is by saving a page in their browser "Favorites" and then using that to start the application. I'm not sure what we can do about that, other than urge them not to.

Unless we can find a way to resolve these issues it seems we are going to have to stop relying on session state as far as possible in our application. Otherwise accidental data corruption can and will occur.

Actually, I have been looking at ways of detecting that a new window has been opened using Javascript - like this:

<script type="text/javascript">

function checkIfSpawned() {

  var lsBrowser = navigator.appName;

  var lsNumPages;

  if (lsBrowser.indexOf("Microsoft") >= 0)

    lsNumPages = 0;

  else

    lsNumPages = 1;

  if (history.length <= lsNumPages) location.replace('f?p=103:4');

}

</script>

i.e. if there is no browser history then bring up a special page instead that simply says "sorry, you can't open this page in a new window".

However, there are other ways to end up with the same session in two or more browser windows (saving page including session_id in Favorites, simple cut and paste...) so I am still looking for other ideas. I think there are two ways in which this can be a problem:

1) Opening the same page with different parameters in two windows simultaneously: the second overwrites the session state of the first, but the first is still rendering and reading the session state. I am exploring whether we can detect that that has happened somehow and raise an error in the corrupted window. For example, perhaps we can save the parameter values into package variables in an On Load, Before Header process and then compare the session state and package values in an On Load, After Footer process: if they are different, the page has been corrupted and we raise an error. (I am very much thinking aloud here, I haven't tried anything yet).

2) With two windows open with same session_id (however that occurs): we cannot rely on the values in session state, only on values in items that are part of the current page. For example, if we have a 2-page wizard with pages 1001 and 1002, then we should not refer to P1001_XXX items when in page 1002. So we have to pass the values from 1001 to 1002 either as parameters, or perhaps by storing them in a table associated with a unique sequence value generated for the transaction, and then passing the sequence value as a parameter. (Again, thinking aloud here).

Tony - This seems plausible. Each page uses the value passed into it. Even if that value changes in session state during page rendering, the original value (in database session package variables) will be used throughout the page view. The committed session state values at any point during that page view might change, but these are not propagated into the package variables in other database sessions (the concurrently running requests).

Scott

If there is anything that sets an item in session state like a process, computation, a page-submitting item, a call to update_cache_with_write, these will commit the new value to the session state table so that it will be visible to other page views using other database sessions. Running the page in debug mode will show you if any events like that are happening (as will inspecting the session state popup report after the page is shown).

Scott

No, it can happen in IE, Firefox, any browser. It isn't any attribute of the window that causes the problem, it is the fact that you now have two windows (or tabs - same issue) in which you are running ApEx with the same session_id. The user thinks he has two separate ApEx sessions, but in fact he only has one. Actions in one window have an impact on the session state used by the other.

Not much. There was a 3.0 enhancement having to do with simultaneous access to public pages. The situation prevented is where multiple users access a public page with a bookmarked link containing the same session ID causing them to access the same apex session at the same time. The fix relies on the IP address of each client (as seen by the application) being different. Sometimes this is not the case even when there are two distinct physical clients, but the fix should help prevent some of these occurrences.

Scott