This has always been a vexing problem to solve for many years. Back in 2007, I remember Carl Backstrom had spent countless hours researching for some handle or unique identifier to a browser window that we could correlate with a distinct browser session cookie, but he was never able to identify a feasible solution. Customers have long asked for a solution, but all we were able to propose were rather cumbersome work arounds (ensure all items necessary for session state were posted with the page, or use the multiple DNS aliases "trick" for each tab).
In October 2015, our friends from BiLog arranged an informal meeting with a couple large enterprise customers from Croatia. Goran, who was from one of the enterprise customers in the insurance industry, stated that the session management behavior of APEX presented a real problem for them. Their typical scenario involved a sales representative who would meet with a customer in-person. Because they wanted to offer insurance quotes or initiate insurance applications on multiple products, the sales representative would open up multiple tabs of their APEX application. Of course, the session state across all of these tabs would collide and effectively corrupt the quoting process. As Goran stated at the time, it became more and more difficult to justify the use of APEX because of this troublesome behavior. I had no immediate answer, but I told him we would redouble our efforts and look at this problem again.
In February of this year, I had one of those lightbulb moments, and realized that we had been thinking about this problem the wrong way, and we needed to turn it inside out. In APEX, there is always a single browser session cookie associated with an APEX session. We were always trying to come up with a way to generate a new and differentiated browser session cookie every time a new tab was opened, and then associate this new browser session cookie with a new APEX session. But the new approach was to simply keep the one and only one browser session cookie, and have this associated with multiple APEX sessions on the server. I expressed my idea to the supremely intelligent Christian Neumueller of the APEX development team, and he went about with a masterful design and implementation of this feature.
In Application Express 5.1, we are introducing a new request to the APEX engine named APEX_CLONE_SESSION. When requested from an existing APEX session, this will generate a new APEX session identifier and associate it with the existing browser session cookie. Additionally, it will copy all of the session state values from the old session to the new session. You, the developer, would have to provide a link for your end users to open up new browser tabs, and include APEX_CLONE_SESSION in the request of the URL. So instead of your end users manually opening up a new tab from your APEX application, you would have to give them a prescribed way to open new tabs - could be a dynamic action or a button or a link. The URL in the new tab should include APEX_CLONE_SESSION in the "Request" portion of the APEX URL.
An example URL would be:
Because we were a bit paranoid about this feature until we could thoroughly vet the security of it, by default, this capability is turned off. You can override this setting for a specific workspace by using the Administration API:
apex_instance_admin.set_workspace_parameter( p_workspace => 'JOELS_WORKSPACE', p_parameter => 'CLONE_SESSION_ENABLED', p_value => 'Y');
or you can enable it for the entire instance using:
apex_instance_admin.set_parameter( p_parameter => 'CLONE_SESSION_ENABLED', p_value => 'Y');
This feature is enabled instance-wide on the Application Express 5.1 Early Adopter site at https://apexea.oracle.com. We would welcome your feedback about this feature. And if you're reading this blog post after APEX 5.1 is generally available, please feel free to try it in your own APEX 5.1 (or later) instance or on https://apex.oracle.com.
Update March 27, 2017: In the production release of APEX 5.1, there is no workspace parameter for CLONE_SESSION_ENABLED. It can only be enabled/disabled at the instance-level and not on an individual workspace basis.