Что действительно хранится в сеансе в ASP.NET?

Question

Мы пытаемся решить, как обрабатывать постоянство объектов через обратные передачи, чтобы избежать получения данных из базы данных при каждом запросе, и я склоняюсь к использованию Session (это приложение для внутренней сети, не будет тысяч пользователей ), но это связано с тем, что я подозреваю, что там хранится только ссылка на реальный объект ...

Кто-нибудь знает наверняка, правда ли это?

Меня всегда учили не чрезмерно использовать объект сеанса, но если он работает таким образом, это не будет большой проблемой ...

Что действительно хранится здесь в сеансе:

Session["myKey"] = myObject;

Фактический сериализованный объект или его ссылка?

Answer 1

Я пробовал это:

Я создал класс и сохранил его экземпляр в сеансе (режим состояния сеанса: InProc). Экземпляр живет в программе aspnet_wp.exe.

Затем я изменил состояние сеанса на SQL Server (все еще без атрибута [Serializable]) и получил следующую ошибку.

Невозможно сериализовать состояние сеанса. В режимах «StateServer» и «SQLServer» ASP.NET сериализует объекты состояния сеанса, и в результате недопустимые объекты или объекты MarshalByRef не допускаются. Итак, для состояния сеанса inProc сериализация отсутствует.

Приветствия ... Мартин

Answer 2

Это зависит от того, какой сеанс вы используете, если вы использовали сеанс inproc, который вы использовали, вызывали ссылку в сеансе, но, ссылаясь на себя, это всего лишь ссылка на объект, он сохраняет весь объект в памяти процесса, поэтому при разработке Вашему приложению крайне желательно знать, сколько данных у вас будет на пользователя и сколько активных пользователей у вас будет в час. Объект в памяти процесса не сериализуется, если вы используете в сеансе proc, но он сериализуется, если вы используете вне сеанса proc, он может иметь реализации по производительности.

Я думаю, что здесь вы можете найти очень хороший обзор сессии и кеша

Answer 3

ASP.NET создает GUID, который по умолчанию хранится в файле cookie (но вы можете указать использование строки запроса) для идентификации пользователя. Объекты, связанные с этим файлом cookie, по умолчанию хранятся на сервере в процессе IIS.

Вы также можете создавать собственные хранилища объектов сеанса (поставщики хранилища состояний сеансов), например, если вы хотите сохранить объекты сеанса вне процесса.

Больше информации здесь:

http://msdn.microsoft.com/en-us/library/ms178587.aspx

Но на самом деле ответить на ваш вопрос ...

Из коробки вы правы в предположении, что хранилище сеансов хранит только ссылку на объект.

Хотя вы можете указать поведение хранилища функциональности сеанса в web.config, я считаю, чтобы добиться сериализации тоже. 3 режима:

• InProc - сессия хранится в виде живых объектов на веб-сервере (aspnet_wp.exe). Используйте конфигурацию «без файлов cookie» в файле web.config, чтобы «взломать» sessionId на URL (также решает проблемы RFC файлов cookie / домена / пути!)
• StateServer - сеанс сериализуется и сохраняется в памяти в отдельном процессе (aspnet_state.exe). State Server может работать на другом компьютере
• SQLServer - сеанс сериализован и хранится на сервере SQL

Выше: http://www.eggheadcafe.com/articles/20021016.asp

Answer 4

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

Тем не менее, для приложения, развернутого в интрасети, где разработчик полностью понимает влияние масштабируемости чрезмерного использования сеансов, как описывает Хуан Мануэль, я делал это много раз и с большим успехом. Да, сеанс может быть перенесен, но это необычный крайний случай - он не происходит достаточно регулярно, чтобы повлиять на приложения браузера с рациональным временем ожидания сеанса.

Я бы сказал, создайте приложение так, как вы предлагаете, Хуан Мануэль, по крайней мере, сначала. Но спрячься там, где ты сохраняешь и получаешь объекты из сеанса (возможно, с классом-оберткой), так что, если приложение потребует, это легко изменить позже.

Answer 5

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

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

Answer 6

Важно помнить, что данные In-Proc Session довольно хрупки ... это означает, что их может не быть, когда они вам больше всего нужны. Если рабочий процесс перезагружается по какой-либо причине poof , то он исчез.