В чем разница между асинхронной функцией сервлета 3.0:
Реализация старого сервлета:
doGet(request,response) {
Thread t = new Thread(new Runnable()
void run(){
// heavy processing
response.write(result)
}
}
t.start();
В сервлете 3.0, если я трачу нить на тяжелую обработку - я зарабатываю еще одну нить в контейнере, но трачу на тяжелую обработку... :(
Может ли кто-нибудь помочь?
Это не сработает. Как только ваш метод doGet завершится, ответ будет завершен и отправлен обратно клиенту. Ваш поток может или не может быть запущен, но он больше не может изменить ответ.
Что такое новая функция асинхронизации в Servlet 3.0, так это то, что она позволяет освободить поток запросов для обработки другого запроса. Случается следующее:
RequestThread: |-- doGet() { startAsync() } // Thread free to do something else
WorkerThread: |-- do heavy processing --|
OtherThread: |-- send response --|
Важно то, что как только RequestThread запустил асинхронную обработку по вызову startAsync(...), он может свободно делать что-то еще. Например, он может принимать новые запросы. Это улучшает пропускную способность.
Функция async для сервлета 3.0 обеспечивает сохранение http-соединения, но освобождение любых неиспользуемых потоков, когда запрос не может быть немедленно подан, но ожидает какого-либо события или, например, когда вы пишете какое-либо приложение кометы/обратного аякса., В приведенном выше случае вы создаете новый поток полностью, поэтому он не должен иметь никакого значения для вас, если вы не хотите, чтобы запрос ожидал какого-либо события.
С наилучшими пожеланиями, Кешав
Существует несколько API-интерфейсов, поддерживающих COMET (длительные HTTP-запросы, где нет проблемы с потоком/запросом). Таким образом, нет никакой строгой необходимости использовать API сервлета 3 для предотвращения потока/запроса. Одним из них является Grizzly движок, который работает в Glassfish 2.11 (example). Второе решение Jetty Continuation. Третий API сервлета 3..
Основная идея заключается в том, что запрос создает некоторый асинхронный обработчик, управляемый контейнером, в котором запрос может подписаться на событие, идентифицированное объектом (например, строка clientid). Затем один асинхронный поток обработки может сказать обработчику, что событие occours, и запрос получает поток для продолжения. Это полностью зависит от выбранного сервера приложений, с помощью которого вы можете использовать API. Каков ваш выбор?
Создание собственных потоков в контейнере сервлетов требует проблем. (Там могут быть случаи, когда вам нужно это делать, но если у вас есть фреймворк, который управляет потоками для вас, вы должны его использовать.)