Добрый день всем.
Поделитесь пожалуйста своими размышлениями на данную тему:
есть веб-приложение, которое по логике должно выполнять в контексте пользовательской сессии поиск по БД. Функция поиска довольно-таки продолжительная и за сим была упрятанна в поток. Т.е. после того, как пользователь выбирает параметры поиска - сам поиск выполняется в отдельном потоке, а пользователь возвращается на страницу, с которой начинал.

"Архитектурка" такая:

пользователь -> параметры+старт_поиска.jsp  -> Controller  -> Search-объект -> поток_поиска
               ^-----------------------------------------------------------+

Так вот вопросец в следующем: могут ли возникнуть варианты, когда в контексте одной сессии с объектом "Controller" будут общаться несколько потоков одного пользователя (ну те, которые из параметры+старт_поиска.jsp что ли  ), и если могут - как грамотнее всего их идентифицировать.
Т.е. надо добиться, что бы каждому объекту Search-объект соответствовал один такой поток.


Построенно на: Apache Tomcat 5.5, Java 1.4, Spring-framework.

Заранее спасибо за Ваши варианты.

1) Не понятно - а как отдавать будешь результаты поиска ?
2) Ну наверно ведь каждый реквест будет создавать один поток - может надо делать разделение на уровне реквеста ?

3) Я бы сделал так - результаты каждого поиска открываются в отдельном окне. Тогда пусть они там бедные висят и ждут ответа. 
А основное окно свободно будет.

Ok. Спасибо большое за отклик.

Я уже, видимо, решил вопрос - просто немного переработал саму логику работы приложения (и нтерфейса).

Оно теперь так и происходит - запускается поток на request, через request/response передаются идентификаторы объектов поиска + несложный pool-объект, которы всем этим делом заведует.

Теперь получается нормалек - после запуска поиска переходит на ту же страницу с которой начинал, но при этом имеет отдельную страницу, на которой с помощью AJAX js-кода происходит отслеживание выполнения всех запущенных им потоков поиска (типа прогрессбары такие). И в любой момент он может по клику перейти на страницу ожидания результатов (или уйти с нее не дождавшись. а потом опять прийти).

Спасибо.

В принципе решение неплохое, но появляется зависимость от JavaScript со всеми ее прелестями: выключенная поддержка, проблемы совместимости браузеров, чужеродный код, который нуждно сопровождать. Если не хочешь со всем этим связываться, можно придумать более простую архитектуру:

сраница результатов имеет URL такого вида:

search.jsp?q=search-term-here

Поскольку для каждого уникального поискового запроса мы имеем уникальный URL, мы можем этот URL напрямую использовать в качестве ключа для хранения объекта Search в атрибутах сессии, не прибегая к излижним ухитрениям в виде искусственного идентификатора запроса:



Тут предполагается, что объект типа Search и есть твой поисковый объект-поток, в котором предусмотрены методы извлечения его текущего состояния.

То есть еще раз: ключевая идея здесь - сопоставлять строку запроса с адресом страницы результатов и использовать этот адрес как ключ к соответствующему объекту Search. На самой странице можно прописать авторефреш через каждые, скажем, десять секунд.

Примерно так и устроены все сценарии типа "Ждите ответа...".