Для клиентской стороны я бы взглянул на Comet , который является технологическим термином для выполнения передачи на стороне сервера в браузер. Есть несколько методов, которые вы можете просмотреть для выполнения этой функции, два из которых вы упомянули (длинный сокет и опрос). Оба эти метода могут быть выполнены с использованием CometD , который представляет собой библиотеку JavaScript, созданную Dojo Foundation с использованием спецификации Bayeux.
Что касается определения того, какой подход лучше, вам нужно взглянуть на свою инфраструктуру. Многие серверы ограничены количеством потоков обработки и могут обрабатывать только определенное количество входящих сокетов одновременно. Как только вы достигнете предела, все последующие сокеты будут поставлены в очередь (или отброшены в зависимости от сервера), пока сокеты не будут освобождены. Tomcat6, наряду с другими более новыми серверами, поддерживает использование API-интерфейсов NIO, что позволяет неблокировать обработку клиентских сокетов, что снимает ограничения на входящие соединения сокетов. Если у вас есть какой-либо веб-сервер, межсетевой экран, прокси-сервер, балансировщик нагрузки и т. Д. Между клиентом и вами, у которого есть ограничение сокетов, вам нужно будет учесть это в своем окончательном решении. Этот подход прекрасно работает, если ваша инфраструктура может его поддерживать, поскольку он обеспечивает вашим клиентам самое быстрое время отклика и снижает стоимость установки и удаления сокетов. Недостатком, как уже упоминалось, является то, что ваша инфраструктура должна поддерживать максимальное количество ожидаемых пользователей (поддержка включает дескрипторы файлов и т. Д.).
Альтернативный метод использования опроса: при добавлении дополнительной служебной информации и более медленном времени отклика из-за не всегда соединения, преимущество заключается в том, что ваш бэкэнд может потенциально использовать меньше ресурсов для поддержки того же числа пользователей (меньше файловых дескрипторов, так далее...).
Что касается вашего второго вопроса, я не совсем уверен, что вы спрашиваете. Если вы пытаетесь получить доступ к информации в сеансе пользователя вне запроса, сгенерированного этим пользователем, это не разрешено в спецификации и будет считаться нарушением безопасности. Если вы говорите о хранении и доступе к информации в сеансе пользователя во время запроса этого пользователя, то это возможно с помощью стандартных API HttpSession. Я бы порекомендовал вам не использовать или пытаться использовать первый подход, так как это не очень хороший дизайн. Если вам необходимо поддерживать пользовательские данные, которые должны быть доступны всем пользовательским потокам, то вы захотите сохранить эти данные вне сеанса отдельного пользователя (базы данных, файла и т. Д.).
Надеюсь, это поможет.