Как работают Action в Контроллерах когда к ним обращаются сразу несколько пользователей?

Question

[coolfusion]

И так! Есть скажем конролерр Home и он содержит action с именем DoSomeThingForUser

class HomeController : Controller 
{
   public ActionResult DoSomeThingForUser(SomeModel model)
   {
      //Что-то делаю с моделью, мб обращаюсь к базе и т.д и возвращаю юзеру 
      return(model)
   }
}

Как будет работать этот action когда скажем 100 пользователей обратятся к нему ?
1-ый пользователь попадет в этот action и он будет lock пока он не выйдет от туда, соответственно остальные 99 пользователей будут его ждать? Или для каждого пользователя создастся отдельный инстанc... хотя это бред, но все таки?

Answer 1

[Станислав Макаров]

Никаких lock-ов в экшене не будет (если вы их сами туда не поставите), и не нужно им там быть. Дефолтовая фабрика контроллеров создает инстанс контроллера на каждый запрос, поэтому 99 пользователей одного ждать не будут. Если нужны подробности - ищите в гугле "asp.net mvc controller instancing", вываливается масса статей с которых можно начать разбираться.

Comments

[coolfusion]

Как насчет static полей в Контроллерах ?

[coolfusion]

Скажем если в этом котролере будет паблик статик поле которое увеличивается на +1 при кажом запросе, тогда когда зайдут 100 пользователей одновременно счетчик будет 100? (Т.е обычное поведение static, одно более для всех инстансов )

[Станислав Макаров]

Доступ к static-полям нужно синхронизировать, т.к. разные инстансы контроллера могут быть созданы в разных потоках. Блокировки для статических полей не нужны только если вы инициализируете их однократно, а в контроллерах используете только на чтение. А, кстати, зачем вам static-поля?

[Станислав Макаров]

Дело в том что static-поля это далеко не лучший способ хранить состояние в ASP.NET приложении и если это не лабораторный тест, то лучше воспользоваться application state.

[coolfusion]

Nipheris: У меня на статике весит Подключение к бд

[Станислав Макаров]

весьма неудачная затея. Вы наполовину убиваете преимущества многопоточной обработки запросов тем, что обращаетесь к базе через одно подключение. Работать с ним вам необходимо будет внутри критической секции, чтобы его не схватили несколько потоков сразу, и по большей части запросы будут ждать друг друга. Также почитайте про database connection pooling в дотнете - там будет написано, что создание и уничтожение объекта подключения вовсе не значит, что создается/уничтожается физическое подключение к базе по сети. Общепринятой практикой считается открытие и закрытие подключения в каждом обработчике.

[coolfusion]

Nipheris: Спасибо добрый человек =) Многое встало на свои места. Буду признателен если есть еще советы.

[coolfusion]

Nipheris: ну или пару линков на литературу/статьи

[Станислав Макаров]

про пул подключений: https://msdn.microsoft.com/en-us/library/bb399543%... . А вообще - любую книгу про современный asp.net mvc (www.amazon.com/gp/product/1430242361), туториалы на www.asp.net/mvc , в том числе по работе с данными через entity framework, поищите также про паттерн Repository. Вот еще неплохое описание жизненного цикла asp.net mvc приложения: i3.asp.net/media/4773381/lifecycle-of-an-aspnet-mv... - как раз написано когда создается контроллер, когда вызываются действия и т.д.

[coolfusion]

Nipheris: Спасибо огромное )

Answer 2

[coolfusion]

Nipheris:

Примерно так kernel.Bind<IDatabaseFactory>().To<DatabaseFactory>().InSingletonScope();