Контроллер (управляемый компонент Spring) вопрос об объеме: Singleton, запрос или сессия?
Вопрос немного давно, это концептуально. Я надеюсь, что это не плохое чтение :)
Я работаю в производительности критический Spring веб-приложение MVC/Tiles (10 000 пользователей типичная загрузка). Мы загружаем экран сотрудника обновления, где мы загружаемся, сотрудник детализирует экран (связанный с бизнес-объектом сотрудника) для обновлений через MultiActionController. На этом экране существует несколько вкладок, но только tab1 имеет updatabale данные. Отдых вкладок является материалом только для чтения для ссылки в основном.
Само собой разумеется, мы решили загрузить эти вкладки только для чтения ленивым способом, т.е. когда каждая вкладка активируется, мы увольняем вызов ajax (одноразовый) за выборку данные из сервера. Мы не загружаем все через метод загрузки представления обновления.Помните: это - одно время, данные только для чтения.
Теперь, я нахожусь в трудном положении. Я сделал другой контроллер мультидействия, названный "AjaxController" для обработки этих вызовов ajax. Теперь, мои вопросы:
- Каков должен быть лучший объем для этого контроллера?
Мысли: Если я заставляю его запросить ограниченный по объему, то 10 000 пользователей вместе могут создать 10 000 экземпляров этого боба: проблема памяти там. Если я сделаю это сессией ограниченный по объему, то каждый будет создан на сеанс пользователя. Это означает, когда 10 000 пользователей входят в систему приложения, независимо от того, поражают ли они методы AjaxController, у них каждый будет боб владеющим.
- Затем действительно ли одиночный элемент является лучшим объемом для этого контроллера?
Мысли: одноэлементный боб будет создан, когда пружина загрузится, и этот самый экземпляр будет обеспечен повсюду. Хорошие звуки.
- Должны методы обработчиков (как fetchTab7DataInJsonFormat) быть статичными и приложенными к классу?
Мысли: В этом случае может наличие статических методов, семантически конфликтуют с объемом? Например: действительно определяет объем = "сессия" / "запрос" +, статические методы имеют смысл? Я спрашиваю, потому что даже при том, что каждый сеанс пользователя имеет свой собственный боб AjaxController, методы обработчиков на самом деле присоединены к классу а не экземплярам. Кроме того, действительно определяет объем = "одиночный элемент" +, статические методы обработчиков имеют смысл?
- Я могу реализовать одноэлементный шаблон разработки в AjaxController вручную?
Мысли: Что, если я управляю созданием: сделайте одиночный элемент GoF в основном. Затем, что может сделать спецификация объема? Сессия/запрос объема, конечно, не может создать несколько экземпляров, может они?
- Если, любым механизмом (бобовый шаблон/статические методы спецификации/дизайна), мне действительно удается иметь один единственный экземпляр AjaxController: эти Статические методы должны будут синхронизироваться? Я думаю не, потому что, даже если СТАТИЧЕСКИЕ методы обработчиков могут говорить с сервисами (которые говорят с DB/WS/MQ и т.д.), которые занимают время, я думаю, что каждый поток запроса, вводящий статические методы, будет возвращен их правом идентификатора потока? Это не похоже на user1, вводит статический метод, и затем user2 вводит статический метод, прежде чем user1 был возвращен, и затем они оба получают некоторые искаженные данные? Это, вероятно, глупо, но я хочу быть уверенным.
Я смущен. Я в основном хочу точно один единственный экземпляр боба контроллера, обслуживающего все запросы на все клиенты.
Критическое Примечание: боб AjaxController не ВВЕДЕН больше нигде, он существует изолированный. Это - методы, поражены через вызовы ajax.
1 ответ
Если бы я делал это, я бы определенно сделал LazyLoadController синглтоном без статических методов в нем и без какого-либо состояния в нем.
Также, вы определенно не должны инстанцировать синглтоны вручную, лучше использовать общий механизм Spring и позволить фреймворку все контролировать.
Общая идея заключается в том, чтобы избегать использования статических методов и/или постоянных данных в контроллерах. Правильным механизмом будет использование некоторого сервисного боба для генерации данных для запроса, а контроллер действует как диспетчер параметров запроса для получения данных в представление. В контроллере не должно быть никаких изменяемых состояний или параллельно опасных вещей. Если некоторые компоненты специфичны для пользователя, система AOP Spring обеспечивает инъекцию компонентов на основе сессии/запроса.
Это что касается хорошей практики в выполнении подобных вещей. Есть кое-что, что нужно уточнить, чтобы дать более конкретный ответ для вашего случая. Правильно ли я понял, что типичный сценарий использования заключается в том, что AjaxController будет передавать некоторые запросы LazyLoadController для получения данных вкладки? Пожалуйста, опишите подробности в комментарии или в вашем вопросе, чтобы я мог обновить свой ответ.
Недостатком статических методов в контроллере является то, что вам придется самостоятельно управлять безопасностью параллельных процессов, что не только чревато ошибками, но и снижает общую производительность. Spring выполняет каждый запрос в своем потоке, поэтому если два одновременных вызова должны использовать какой-то статический метод и есть общие ресурсы (поэтому вам нужно использовать оператор synchronize или блокировки), один из потоков должен будет ждать, пока другой завершит работу в защищенном блоке. С другой стороны, если вы используете stateless сервисы и избегаете наличия данных, которые могут быть общими для нескольких вызовов, вы получите более высокую производительность и отсутствие необходимости иметь дело с одновременным доступом к данным.