Состояние сеанса

Содержимое карты покупателя, о которой упоминалось в предыдущем разделе, представляет состояние сеанса (session state) — в том смысле, что данные, отображаемые в карте, имеют отношение только к конкретному сеансу. Это состояние действительно в контексте конкретной бизнес-транзакции, т.е. отделено от других сеансов и охватываемых ими бизнес-транзакций. (Здесь подразумевается, что каждая бизнес-транзакция функционирует в контексте одного сеанса и в каждом сеансе в один и тот же момент времени выполняется всего одна бизнес-транзакция.) Состояние сеанса отличается от того, что принято называть хранимыми данными (record data), т.е. от информации, которая размещается в базах данных и становится доступной для сеансов всех пользователей, наделенных соответствующими полномочиями. Чтобы информация состояния сеанса приобрела статус хранимых данных, она должна быть зафиксирована в базе данных.

Поскольку состояние сеанса существует в контексте определенной бизнес-транзакции, оно обладает многими свойствами транзакции. Одно из любопытных следствий этого факта связано с эффектом свойства согласованности. Например, в процессе редактирования информации полиса страхования текущее состояние полиса может быть некорректным. Пользователь изменяет некоторое значение, посредством запроса отсылает его системе, а последняя возвращает ответ, уведомляя об ошибке. Значение является частью состояния сеанса, но оно неверно. Состояние, таким образом, не всегда удовлетворяет заданным условиям в период, когда сеанс активен,— критерии достигаются только после фиксации результатов бизнес-транзакции.

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

Наиболее очевидный пример — одновременное обращение двух пользователей к одному полису. Рассмотрим две записи: полис как таковой и сведения о клиенте. Запись полиса включает величину риска, которая частично зависит от значения почтового кода в записи клиента. Пользователь начинает редактировать полис и по прошествии 10 минут выполняет какое-то действие, которое приводит к открытию и отображению записи клиента. Допустим, что в то же время другой пользователь изменяет почтовый код и величину риска; это неминуемо приведет к ситуации несогласованного чтения.

Не все данные, хранимые на протяжении сеанса, трактуются как состояние сеанса. Во время протекания сеанса некоторая информация может кэшироваться, причем не в целях сохранения, а для повышения производительности системы. Поскольку данные кэш-памяти можно удалить без потери функциональности, они принципиально отличаются от состояния сеанса, которое подлежит обязательному сохранению в промежутках между циклами обработки запросов.

Способы сохранения состояния сеанса

Как же все-таки сохранять информацию состояния сеанса, если это действительно нужно делать? Можно предложить три основных, хотя и не вполне исключающих друг друга, решения.

Типовое решение сохранение состояния сеанса на стороне клиента (Client Session State) предусматривает сохранение информации о состоянии сеанса на клиентской машине. Существует несколько вариантов достижения цели: кодирование данных для Web-представления, использование файлов cookie, сериализация информации в скрытых полях Web-формы и сохранение объектов в приложении толстого клиента.

Сохранение состояния сеанса на стороне сервера (Server Session State) может быть, в частности, настолько простым, как размещение данных в памяти на период между циклами обработки запросов. Однако обычно используется механизм долговременного хранения информации в виде некоего сериализованного объекта. Объект сберегают в файловой системе сервера приложений или в источнике данных, допускающем совместный доступ, например в виде простой таблицы базы данных с двумя полями: первое — ключ сеанса, а второе — содержимое сериализованного объекта.

Решение сохранение состояния сеанса в базе данных (Database Session State) также предусматривает использование носителей сервера, но с более тщательным структурированием информации по таблицам и полям базы данных.

Выбор подходящего варианта сопряжен с преодолением ряда препятствий. Прежде всего необходимо учесть возможности канала связи между клиентом и сервером. Решение сохранение состояния сеанса на стороне клиента предполагает активный обмен информацией о состоянии сеанса при обработке каждого запроса. Если речь идет всего о нескольких полях, это не проблема, но с увеличением объемов данных возрастает и нагрузка на канал.

Конечно, без некоторых данных просто не обойтись, поскольку они, например, подлежат воспроизведению на уровне представления. Но при использовании решения сохранение состояния сеанса на стороне клиента с каждым запросом приходится передавать все данные, даже если они не будут визуализированы. Таким образом, это решение целесообразно применять только тогда, когда объем данных, определяющих состояние, достаточно мал. Помимо того, следует позаботиться об аспектах безопасности и целостности информации. Если вы не займетесь шифрованием данных, у вас будут все основания полагать, что любой злоумышленник сможет изменить состояние вашего сеанса.

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

Если пользователей слишком много, для повышения пропускной способности системы следует рассмотреть возможность кластеризации аппаратного обеспечения и подумать о необходимости переноса сеанса (session migration) с одного сервера на другой по мере завершения обработки одного запроса и поступления других. Противоположная схема — привязка к серверу (server affinity) — предполагает, что все запросы, инициируемые в рамках одного сеанса, обслуживаются конкретным сервером. Модель переноса сеанса позволяет достичь баланса производительности системы, особенно в тех случаях, когда сеансы длинны. Однако при использовании типового решения сохранение состояния сеанса на стороне сервера она может стать довольно неуклюжей, поскольку зачастую передача информации о состоянии сеанса с одного сервера на другой сопряжена с дополнительными трудностями. Впрочем, можно отыскать и компромиссные варианты, стирающие грани между решениями сохранение состояния сеанса на стороне сервера и сохранение состояния сеанса в базе данных.

Модель привязки к серверу также далеко не безгрешна. Пытаясь гарантировать возможность привязки, кластерная система не всегда способна проследить за всеми вызовами, чтобы обнаружить, к каким сеансам они относятся. В результате привязка обеспечивается за счет того, что все вызовы со стороны конкретного клиента направляются одному и тому же серверу. Часто клиент распознается по IP-адресу. Но если клиент отделен от сервера приложений прокси-сервером, это значит, что тем же IP-адресом могут обладать и многие другие клиенты, и все они будут «привязаны» к тому же серверу приложений, что никак не назовешь удачным вариантом развития событий.

Если серверу необходимо обратиться к состоянию сеанса, последнее должно быть представлено в доступной форме. При использовании типового решения сохранение состояния сеанса на стороне сервера искомое состояние, как можно полагать, прямо «под рукой». Применяя решение сохранение состояния сеанса на стороне клиента, вам, вероятно, придется обеспечить преобразование данных в нужную форму. Решение сохранение состояния сеанса в базе данных, естественно, вынуждает обращаться за информацией о состоянии сеанса к базе данных (и, помимо того, нередко выполнять дополнительные преобразования). Каждый подход по-своему определяет показатели быстроты реагирования системы, которые напрямую зависят от объема и структурной сложности данных состояния.

Одна из самых досадных проблем функционирования многих систем связана с нештатным прерыванием сеанса, когда клиент просто отключается от сервера, не «пообещав» ничего конкретного. В таком случае наиболее выигрышно выглядит решение сохранение состояния сеанса на стороне клиента, позволяющее серверу легко позабыть о неблагодарном клиенте. При использовании решения сохранение состояния сеанса на стороне сервера сеанс можно трактовать как прерванный только по истечении заданного лимита времени, но вам придется побеспокоиться об удалении информации о состоянии сеанса.

Заслуживает внимания и ситуация, связанная с выходом из строя системы в целом: сбоем приложения клиента, отказом сервера и/или разрывом сетевого соединения. Решение сохранение состояния сеанса в базе данных обычно позволяет поладить со всеми тремя неприятностями. «Выстоит» ли информация при условии сохранения состояния сеанса на стороне сервера, зависит от того, предусматривалось ли сбережение резервной копии данных объекта сеанса в энергонезависимом хранилище. Результаты сохранения состояния сеанса на стороне клиента, разумеется, «погибнут» вместе с клиентом, если такое вдруг случится, но, вероятно, останутся в неприкосновенности при других возможных авариях.

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