забыл никСмех смехом, но термин JMS проскочил уже по-моему на второй странице :)
На первой. ;)
Ну, и JMS, в основном, усилино использует базу.
И, в целом, решение держать логи где-либо, при том что их можно отдать сразу тоже не самое лучшее.

Сергей Арсеньев Есть плюсы - есть минусы.

Давайте обсудим плюсы polling-а в данном случае? Очень интересно в чем они?

Сергей АрсеньевВопрос был, как мне показалось, где держать Application scope переменную.

Переменная не Application Scope, а session scope.
Переменная не просто переменная а целый log.

Сергей АрсеньевPoll, как мне кажется, легче переживает смерть web frontend (и другие временные трудности в канале передачи).
[/quot]
Да, для server push нужно убедится, что клиент умеет восстанавливать соединение. В Poll это не актуально.

Сергей Арсеньев Девушке как раз и нужна была Application scope.

Это у вас инсайдерская инфа или как вы поняли?

Сергей АрсеньевИбо с ней работать должна была не одна сессия (не один процесс и ...

Юзер запускает процесс и получает лог. Где видно то что разные юзеры должны получать лог? Где написано что юзер должен с другого компа уметь прочитать лог процесса?

Сергей Арсеньев...не на одном компе).

И давно у нас Application Scope реплицируется? Или про какие "компы" речь?

Сергей Арсеньев А то, что это лог (hashmap) состояний внешних процессов, как-то проидентифицированных.
Это уже частности.
ОК. Уговорили.

Сергей Арсеньев Чуть выше. Лог Юзеру на не нужен. Нужен барграф процента выполнения шеловского скрипта по запуску БД и пр.

Вот здесь: 13785688
Oksana вычитывает весь выхлоп команды чтобы показать юзеру. Как получить % выполнения при этом, я не очень понимаю.

Сергей Арсеньев IMHO. Написать два сервлета общающихся через App scope переменную (хоть в БД хранящуюся) - самый простой рабочий говнокод. Один сервлет (jsp etc) отвечает пользователю что происходит с его задачей №100500, второй дергается из скрипта (например через wget) и отчитывается о том что в задаче №100500 строчка n выполнена перехожу на n+1.
Плюс прочистка, плюс дополнительные агенты надзора плюс рефакторинг до бесконечности.
Я уже описал свой вариант решения выше. На long polling оно всё делается на много проще - ничего нигде хранить вообще не нужно, решить нужно только одну проблему, использовать реализацию с нормальным восстановлением если клиент отвалился по таймауту или другой причине.
Хотя, конечно, возможна проблема с тем, что если не вычитывать выхлоп, пока клиент отвалился, то серверный процесс замрет в ожидании. В этом случае я бы сделал буфер и при его переполнении просто сбрасывал его с другой стороны. Если юзера нет очень долго то и лог ему вряд ли нужен. Только состояние успешно или нет.