Являются ли Spring контроллеры MVC одиночными?

У меня есть запрос относительно Spring 3 MVC @Controllers. Когда приходит запрос, создает ли контейнер новый экземпляр контроллера для каждого запроса (аналогично Action в Struts 2 - ThreadLocal ActionContext), или один экземпляр отвечает на все запросы? По умолчанию находятся ли контроллеры beans синглтоны в контексте?

Каковы рекомендации/рекомендации для приложения Spring 3 MVC? Эти параметры настраиваются? Должны ли они быть настроены? Много ли это изменится, если моя среда представляет собой кластерную среду - я думаю, это не должно быть, поскольку jvm/контейнеры будут отличаться, но некоторые авторитетные предложения будут приветствоваться.

Я прочитал документацию Spring, но, вероятно, я ее пропустил. Любой "это то, как мы реализовали вид" ответов/указателей/ссылок, было бы полезно Спасибо.

Ответы

Ответ 1

Контроллеры

Spring - это синглтоны (всего один экземпляр каждого контроллера для веб-приложения), как и сервлеты. Как правило, нет смысла изменять это поведение (если это возможно). См. О безопасности потоков сервлета для общих ошибок, также применимых к контроллерам.

Если ваше кластерное приложение делает столько, сколько вы можете, чтобы избежать состояния. Состояние в контроллерах потребует синхронизации, чтобы избежать проблем с потоками. Также вы, вероятно, будете копировать это состояние на разных серверах - очень дорого и неприятно.

Ответ 2

Действия Struts2 не являются одиночными, потому что они несут состояние. Struts2 использует свойства javabeans для самого действия, чтобы переносить входящие данные запроса и подвергать его различным слоям фреймворка.

Spring, с другой стороны, использует объект модели, который передается контроллеру. Сам контроллер не имеет состояния, поэтому одноэлемент имеет смысл.

Ответ 3

Контроллер - это синглтоны, поэтому можно избежать создания множества экземпляров по ключевому слову new, если в Webapp обрабатывается множество запросов одновременно. Использование синтаксиса контроллера также может облегчить нагрузку на JVM за счет уменьшения младшего GC.