Сессия ASP.NET и проблема с параллельными запросами

Эта статья будет интересна прежде всего тем, кто, явно или неявно, использует сессию ASP.NET в своих приложениях. Тем же, кто принципиально не использует сессию, можно почитать для общего развития – вдруг пригодится на будущее.

И, поверьте мне, она будет невероятно интересна разработчикам таких приложений, которые могут обрабатывать несколько небыстрых одновременных запросов от одного пользователя. Показательный пример – одновременное скачивание нескольких больших файлов. Это реальная проблема, с которой столкнулись мои коллеги и на отладку которой было потрачено неадекватно много времени.

Проблема состоит, в первую очередь, в неочевидности следующего факта: в рамках одной сессии (одного SessionID) параллельные запросы выполняются по очереди, если обработчики поддерживают сессию. При этом обращений к сессии в обработчике может не быть вообще – важна только поддержка сессии и её предварительная инициализация. В нашем примере это означает то, что пока не закачается один файл, закачивание других не начнется.

В принципе, ситуация с конкурентными запросами в рамках одной сессии описана в статье MSDN ASP.NET Session State Overview. Но есть нюансы. Во-первых, это один неприметный абзац в конце статьи (вместо выделенного блока в начале). Во-вторых, MSDN не раскрывает многих неочевидных моментов. И, что важно, ни один из моих знакомых ASP.NET разработчиков не знал об этой особенности.

Заинтересовались? Тогда продолжаем. Я сформулирую несколько правил работы сессии и покажу на примере, что они верны.

Несколько запросов и сессия ASP.NET

MSDN глаголет следующее:

Access to ASP.NET session state is exclusive per session, which means that if two different users make concurrent requests, access to each separate session is granted concurrently. However, if two concurrent requests are made for the same session (by using the same SessionID value), the first request gets exclusive access to the session information. The second request executes only after the first request is finished. (The second session can also get access if the exclusive lock on the information is freed because the first request exceeds the lock time-out.)

То есть, получаем основные правила:

• У разных сессий с одновременными запросами все в порядке.
• Если в одной сессии будет несколько параллельных запросов, выполнятся они будут по очереди. Кто успел первым – тот выполнится до конца (или до остановки по таймауту), и только потом начнется обработка второго.

Несколько легче ситуация с обработчиками запросов которые помечены относительно сессии как “только для чтения”. Далее для простоты буду называть это режимом ReadOnly (не путать с session mode – InProc, StateServer и т.п.). Они не блокируют друг друга, однако могут быть заблокированы запросом, который может писать в сессию:

However, read-only requests for session data might still have to wait for a lock set by a read-write request for session data to clear.

И повторюсь, потому что это важно – если обработчик запроса не помечен особым образом, блокируются любые запросы, даже те, которые не обращаются к сессии. Для воспроизведения блокировки параллельных запросов важно только то, что хранилище для сессии должно быть предварительно инициализировано.

Экспериментальное подтверждение правил

Чтобы не было вопросов по поводу возможных трактовок ситуации, имеет смысл написать приложение, которое воспроизводит вышеописанное поведение. А заодно можно показать, что без обращения к сессии подобных проблем не возникает.

Для иллюстрации режима “только для чтения” можно реализовать HttpHandler с маркерным интерфейсом IReadOnlySessionState вместо IRequiresSessionState. Мне показался более быстрым в реализации вариант со страницами директивой @Page.

Далее подразумевается работа в Microsoft Visual Studio 2010 и .NET 4.0. Детали реализации в других версиях могут незначительно отличаться. Достаточно создать проект “ASP.NET Empty Web Application”, но вы можете добавить страницы и в существующий проект.

Отмечу также, что некоторые браузеры (например, Opera) создают разные сессии для нескольких страниц одного пользователя, поэтому пример лучше проверять с помощью Internet Explorer (в моем случае IE9).

Страница инициализации сессии

Кстати, есть еще одна особенность сессии, которая может быть вам интересна. Начиная с .NET 2.0, хранилище для сессии не инициализируется до первого обращения к ней.
[UPDATE] Еще один способ инициализации сессии – добавить метод Session_Start в Global.asax (спасибо Юрию за комментарий).

По этой причине, чтобы показать независимость блокировок от обращений к сессии, создадим страницу InitSession.aspx со следующим скриптом:

<script runat="server">

    protected override void OnLoad(EventArgs e)

    {

        base.OnLoad(e);

        Session["0"] = ((int?)Session["0"] ?? 0) + 1;

        Response.Write(Session["0"]);

        Response.Write("<br/>");

        Response.Write(Session.SessionID);

    }

</script>

Можете провести эксперимент – сначала закомментировать обращение к сессии и оставить только вывод идентификатора сессии (который не инициализирует хранилище). В этом случае он будет каждый раз разным.

Медленная страница

Добавим к проекту страницу SlowPage.aspx, в явном виде зададим доступ к сессии только для чтения и напишем обработчик для Load:

<%@ Page Language="C#" EnableSessionState="ReadOnly" %>

<script runat="server">

    protected override void OnLoad(EventArgs e)

    {

        base.OnLoad(e);

        System.Threading.Thread.Sleep(30*1000);

    }

</script>

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

Тестовая страница

Добавим к проекту страницу TestPage.aspx и напишем в ней следующий код:

    protected override void OnLoad(EventArgs e)

    {

        base.OnLoad(e);

        Response.Write(Session.SessionID);

    }

</script>

Как вы видите, от Slow.aspx её отличает только отсутствие режима ReadOnly и Thread.Sleep.

Проверка режима ReadOnly

Теперь откроем в IE InitSession.aspx, затем SlowPage.aspx, а в другой вкладке TestPage.aspx. При обновлении по F5 страницы TestPage.aspx (пока грузится SlowPage.aspx) никаких блокировок не происходит.

Что произойдет, если перенести установку режима ReadOnly из SlowPage.aspx в TestPage.aspx? Теперь, после открытия SlowPage.aspx, TestPage.aspx будет блокироваться в течении 30 секунд. Это подтверждает сказанное ранее – ReadOnly запросы блокируются обычным запросом поддерживающим сессию.

Проверка обычного режима

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

Разумеется, при отключении поддержки сессии никаких блокировок не происходит (только нужно убрать обращение к SessionID).

Что делать?

Что же делать в ситуации, когда мы хотим использовать сессию, но не хотим блокировать некоторые параллельные операции? Учитывая нечеткую формулировку вопроса (а частных случаев слишком много), вариантов множество, я перечислю только некоторые из них:

• Использовать вместо сессии другой механизм хранения сессионных данных (свой сервис).
• Написать свой или использовать сторонние неблокирующие провайдеры сессии.
• Там где сессия только читается использовать режим ReadOnly. С оговорками, упомянутыми выше.
• Отключать сессию для тех операций, которым она не нужна. Об этом подробнее в следующий раз.

Резюме

Хотя блокировка запросов внутри одной сессии ASP.NET, разобранная в этой статье, вполне логична (можно провести аналогию с транзакцией в БД), в официальной документации это поведение описано довольно мутно.

Поэтому повторюсь. В рамках одной сессии (одного SessionID) параллельные запросы выполняются по очереди, если обработчики поддерживают сессию. Обращения к сессии при этом не учитываются. Исключение составляет режим ReadOnly, который не блокирует другие запросы, но сам может быть заблокирован.

Если будет время и интерес читателей, напишу еще о сессии ASP.NET – в частности, про нестандартные провайдеры сессии и варианты отладки обращений к сессии. Также расскажу подробности о режиме ReadOnly, который не всегда ReadOnly :)


Если у вас есть замечания, пожелания или новые темы – пишите в комментариях, твиттер или на olegaxenow.reformal.ru. Постараюсь учесть.