У меня есть следующий сервлет sitebricks. Foo.get()
доступен как GET
в /foo/bar
. Я развернул сервлет в GAE.
@Service
@At("/foo")
@Singleton
public class Foo {
@Get
@At("/bar")
public Reply<?> bar(Request<String> request, HttpSession session) {
// access request scoped HttpSession
}
}
Если я правильно понимаю sitebricks, и Request, и HttpSession внедряются sitebricks (возможно, с помощью Guice а>). Это также гарантирует, что HttpSession является локальным для текущего запроса. Параллельные запросы будут выполняться для одного и того же экземпляра Foo
, поскольку класс помечен @Singleton
(см. документы Guice). Но даже при одновременных запросах, поступающих на одну и ту же JVM, каждый вызов bar()
будет иметь свой собственный HttpSession на основе JSESSIONID, переданного клиентом. Верны ли все эти предположения?
При выполнении нагрузочных тестов для моего приложения я заметил, что при очень низкой скорости HttpSession, переданный sitebricks/Guice, имеет значение null. В настоящее время я устраняю эту проблему с помощью службы поддержки Google. Но помимо GAE - что может быть причиной этого с точки зрения sitebricks/Guice?
Я найден фрагмент кода, который внедряет Provider в конструктор. Означает ли это, что я могу/должен получить HttpSession, вызвав Provider.get()
вместо того, чтобы позволить sitebricks вводить его в качестве параметра метода?
Похожие вопросы:
- Provider‹HttpSession› не внедряется
- Как @Внедрить объект HttpSession в класс сервисного уровня (DAO) в GWT с помощью Guice?
- Вставьте значение @SessionScoped в фильтр с помощью Guice
Обновления
- Я удалил параметр HttpSession из всех методов сервлета, таких как
bar
. Я внедрилProvider<HttpSession>
в сервлет и вызвалprovider.get()
, чтобы получить сеанс. Тесты, которые я провел до сих пор, показывают, что это более надежно, чем получениеHttpSession
из параметров. Тем не менее, я не уверен, предоставляется ли сеанс sitebricks или самим GAE. Предоставляется ли HttpSession контейнером сервлета?