Рассматривайте пользователя, делающего несколько запросов одновременно, мне нужно заблокировать весь код, который работает с сеансом?
Если, например, у меня есть следующий сценарий, где на одной вкладке его браузера пользователь открывает страницу, а во втором он выходит из системы.
Запрос 1:
if(Session["user"] != null)
lblName.Text = Session["user"].Name;
Запрос 2:
if(logout)
Session["user"] = null;
Возможно ли, что Request 1 генерирует исключение NullPointerException при доступе к свойству Name? Нужно ли мне блокировать код в запросе 1, чтобы убедиться, что пользователь все еще существует после проверки на нуль? Или ASP.NET справляется с этим автоматически каким-то образом?
Как всегда, ответ зависит от того, что вы подразумеваете под "безопасностью". В ASP.NET каждый запрос получает эксклюзивный доступ к его состоянию сеанса. Это означает, что вам не нужно беспокоиться о синхронизации доступа в рамках одного запроса. Если Session [ "user" ] не является нулевым, то он будет не нулевым в течение всей продолжительности текущего запроса. В вашем примере запрос 1 никогда не приведет к исключению нулевой ссылки.
Два запроса к приложению ASP.NET для одного и того же сеанса, где обработчики не используют IReadOnlySessionState интерфейс маркера или имеют EnableSessionState="ReadOnly" включен для ваших страниц, будет сериализован во время выполнения ASP.NET, чтобы гарантировать согласованность состояния. Поэтому, если у вас есть две страницы, которые могут писать в состояние сеанса, они будут доступны независимо от того, что клиент делает на их стороне.
Это до вашего кода приложения, чтобы сигнализировать ASP.NET с помощью описанных методов, будет ли страница/обработчик собираться писать в состояние сеанса. Если вы этого не сделаете, все запросы будут сериализованы, и производительность вашего веб-приложения пострадает.
В ASP.NET модуль использует пару блокировок чтения/записи за сеанс, поэтому запрос 1 будет иметь последовательные чтения и Запрос 2 будет блокироваться до завершения запроса 1.
Да, сеанс является потокобезопасным.
Нет необходимости блокировать. Однако необходимость проверять значения никогда не перестают быть существенными.
Обновление
Проверьте @Peter Ruderman ответ:)
У меня будет пристойность не копировать его:)