Управление данными сеанса webapp / поток контроллера для нескольких вкладок

У меня есть веб-приложение на Java, которое хранит некоторые данные в сеансе. Данные в сеансе изменяются по мере взаимодействия пользователя с приложением (например, потоком управляет контроллер, каждый контроллер имеет несколько страниц формы, на каждой странице формы некоторые данные обновляются в сеансе, и поток переходит к следующей странице формы).

Проблема в том, что некоторые пользователи открывают более одной вкладки в приложении, причем каждая вкладка имеет свой шаг в потоке. В этот момент данные в сеансе перепутаны, так как вкладки используют один и тот же сеанс (приложение использует сеансы, управляемые файлами cookie).

Указание пользователям использовать разные браузеры, чтобы не использовать один и тот же идентификатор сеанса (например, одно окно Firefox и один IE window) не вариант, так как наверняка в какой-то момент кто-то забудет это сделать и вместо этого будет использовать вкладки, таким образом испортив свои данные.

Добавление некоторых проверок, которые обнаруживают, что другой поток запрашивается с другой вкладки, и отображают сообщение пользователю о том, что это не разрешено, тоже не вариант, поскольку это бесит пользователей, а мы не хотим этого, не так ли? : D

Дело в том, что использование другой вкладки полезно для пользователей, потому что они более эффективны в том, для чего они используют приложение, поэтому я оставляю этот вариант. Но теперь возникает вопрос , как лучше всего управлять данными одного сеанса для большего количества вкладок?

Я подумал о том, чтобы контроллер генерировал токен при запуске потока и передавал этот токен на каждую страницу формы. который, в свою очередь, отправляет его обратно, чтобы идентифицировать себя. Если другая вкладка запрашивает то же действие контроллера при продолжающемся потоке, создайте другой токен и передайте его.

В основном, Я хочу, чтобы у каждого потока был токен, и внутри сеанса я не буду просто хранить один набор данных, но буду иметь набор данных для каждого токена, а затем сопоставить запросы на основе токена.

Теперь проблема в том, что этот подход потребует большого количества переписываний приложения, и мне было интересно, есть ли лучшая практика для управления такой ситуацией или кто-то может предложить другие подходы. Я открыт для идей.

Вы сталкивались с такой ситуацией? Как вы с этим справились?