Managing webapp session data/controller flow for multiple tabs

Question

I have a Java web application which stores some data in the session. The data in the session changes as the user interacts with the application (e.g. flow is managed by a controller, each controller has several form pages, on each form page some data is updated in the session and flow goes to the next form page).

The problem is that some users are opening more than one tab to the application, each tab with a different step in the flow. At this point data in the session is messed up since the tabs share the same session (app uses cookie managed sessions).

Telling the users to use different browsers to avoid sharing the same session id (e.g. one Firefox window and one IE window) is not an option since surely at some point somebody will forget to do this and instead use tabs, thus messing up their data.

Adding some verifications that detect that another flow is requested from another tab and display a message to the user saying this is not allowed is not an option either since it pisses of the users and we don't want that do we? :D

The fact is that using another tab is useful for the users because they are more efficient in what they use the application for, so I am keeping this option. But the question now is how best to manage the one session data for the more tabs?

What I thought of, was to have the controller generate a token when it starts the flow and pass this token to each form page which in turn sends it back to identify itself. If another tab requests the same controller action when there is an ongoing flow then generate another token and pass that around.

Basically, I want each flow to have a token and inside the session I won't just keep one set of data but have a set of data for each token and then match requests based on the token.

Now the problem is that this approach will need a lot of rewritings to the application and I was wondering if there is a best practice for managing such a situation or can someone suggest other approaches. I am open to ideas.

Have you encountered this situation? How did you handle it?

Solution

This is usually done by assigning a windowId for each tab/window and passing it on each request. Jsf supports this via orchestra. Spring mvc will support it in the next version.

I recently needed this for a simple case, so I implemented it myself. Took half an hour. However, my scope was very limited:

• pass a windowId with each request, and return it back for the next request. The first time - generate it.
• for any attribute you want to store in the session, put a Map<String, Object> where the key is the windowId

Comments

[Matt Ball]

There is no difference between using separate tabs and separate windows. Session scope is browser-wide, because it is implemented using cookies (most often). What technology stack are you using? JSP+servlets? JSF?

[Gabriela]

@Matt Ball: I'm using Servlets+JSPs. I've updated my question. I know session spans the entire browser that is why I mentioned the two windows to be one IE the other Firefox.

[Matt Ball]

Ok, it was the wording "use different windows instead of a tab to avoid sharing the same session id" when you really mean "use different browsers."

[Gabriela]

Thank you for the answer. Is this what you are referring to? myfaces.apache.org/orchestra/myfaces-orchestra-core/…

[Bozho]

yes. that's it. I've used it and it works smoothly. But it requires spring.

[fforw]

Where did you get the impression that Spring MVC will handle conversations soon? AFAIK it's not planned. Spring Webflow is built around a conversation/flow concept. Conversations are meant to be optionally parallel conversations (windows), flows allow the handling of browser back and forward by implementing a versioned data store.

[Bozho]

@fforw from a presentation by Juergen Hoeller from December. It might have been dropped, however.

[Rodrigo Ruiz]

How exactly do I pass that windowId with every request without changing the url? in a get request for example.

[Ron Burk]

I (have to) use a product that tries to do a version of that. It often does not end well. Users still want to use standard browser navigation, and you can't stop them from opening a new tab and hoping for the best. I'm sure it's possible to do a better job at this than I've experienced, but I doubt it's trivial.