Работает ли Session с поддержкой многопоточности? - PullRequest
22 голосов
/ 10 августа 2011

Рассмотрим, как пользователь делает несколько запросов одновременно, должен ли я заблокировать весь код, который работает с сеансом?

Если, например, у меня есть следующий сценарий, где на одной вкладке его браузерапользователь открывает страницу и во втором он выходит из системы.

Запрос 1:

if(Session["user"] != null)
    lblName.Text = Session["user"].Name;

Запрос 2:

if(logout)
   Session["user"] = null;

Возможно ли, что запрос 1 выбрасываетNullPointerException при доступе к свойству Name?Нужно ли блокировать код в запросе 1, чтобы убедиться, что пользователь все еще существует после проверки на ноль?Или ASP.NET как-то справляется с этим автоматически?

Ответы [ 4 ]

14 голосов
/ 10 августа 2011

Два запроса к приложению ASP.NET для одного и того же сеанса, где обработчики не используют интерфейс маркера IReadOnlySessionState или имеют включенный EnableSessionState="ReadOnly" дляВаши страницы будут сериализованы средой выполнения ASP.NET, чтобы гарантировать согласованность состояния.Таким образом, если у вас есть две страницы, которые могут записывать в состояние сеанса, они будут доступны последовательно, независимо от того, что клиент делает на их стороне.

Код вашего приложения должен сигнализировать ASP.NET с помощью упомянутых методов, собирается ли страница / обработчик выполнять запись в состояние сеанса.Если вы этого не сделаете, все запросы будут сериализованы, и производительность вашего веб-приложения снизится.

10 голосов
/ 10 августа 2011

Как всегда, ответ зависит от того, что вы подразумеваете под «безопасностью». В ASP .NET каждый запрос получает эксклюзивный доступ к своему состоянию сеанса. Это означает, что вам не нужно беспокоиться о синхронизации доступа в рамках одного запроса. Если Session ["user"] не равен NULL, то он будет иметь значение NULL на протяжении всего текущего запроса В вашем примере запрос 1 никогда не вызовет исключение нулевой ссылки.

5 голосов
/ 10 августа 2011

В ASP.NET модуль Session использует пару блокировок чтения / записи на сеанс , поэтому запрос 1 будет иметь согласованное чтение, а запрос 2 будет блокироваться до завершения запроса 1.

1 голос
/ 10 августа 2011

Да, сессия является поточно-ориентированной.

Нет необходимости блокировать что-либо.Однако необходимость проверить значения никогда не перестанет быть существенной.

Обновление

Проверка ответа @Peter Ruderman:)

У меня будет порядочность не копировать это :)

...