Как наилучшим образом решить проблему переменной состояния сеанса InProc \ multi instance?

Question

Недавно мне было поручено исправить довольно неприятную ошибку, вызванную неправильным использованием состояния сеанса. У нас есть веб-приложение asp.net, которое выполняется на одном сервере с использованием состояния сеанса inproc. Основной дизайн состоит в том, что типизированный набор данных загружается из базы данных и сохраняется в состоянии сеанса с использованием общего имени переменной сеанса, такого как Session ["dataset"] = набор данных. После того, как данные сохранены в сеансе, пользователь редактирует данные, набор данных извлекается из сеанса, обновляется и отправляется в базу данных для обновления. Этот тип редактирования / хранения данных используется в нескольких веб-формах, которые в основном делают одно и то же. Все хорошо, пока пользователь не попытается запустить второй экземпляр приложения, и данные, хранящиеся в переменной сеанса, могут быть перепутаны.

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

1. Установить sessionState cookieless = "false" (каждый новый экземпляр получает уникальный идентификатор сеанса) PROS - самое простое решение, практически не нужно менять код CONS - guid в URL, пользователь может редактировать guid, guid можно скопировать

2. Используйте настраиваемый ключ сеанса для каждого экземпляра (передайте ключ сеанса и объедините его «набор данных» + имя ключа сеанса, чтобы каждый экземпляр имел уникальную переменную сеанса) PROS - нет ссылки в URL CONS - большая часть изменений кода, возможно хрупкая

3. Удалите переменную сеанса (Загрузите набор данных из базы данных во второй раз для редактирования) PROS - освобождает ресурсы сервера, больше не зависит от состояния сеанса CONS - снижение производительности, большое количество изменений кода

Кто-нибудь знает какие-либо другие возможные решения? Спасибо

Answer 1

Вы утверждаете, что третьим вариантом будет снижение производительности (вообще удалите объект сеанса), но пробовали ли вы его?

Я спрашиваю, потому что сериализация стандартного набора данных общеизвестно ресурсоемка на стороне сервера - во многих случаях объем памяти может увеличиваться на порядок (набор данных объемом 1 МБ может занять 10-15 МБ для сериализации ), а также процессорное время для этого.

Я бы порекомендовал взглянуть на попытку 3 и тестирование, чтобы увидеть, обоснованы ли ваши опасения или вы действительно видите прирост производительности;)

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

Answer 2

Ну, единственный способ гарантировать, что два экземпляра не получат доступ к одному и тому же состоянию сеанса, - это сделать что-то с url / POST-данными. Вот с чем вам нужно играть.

Возможно, проще всего будет использовать cookieless = true и надеяться, что все URL будут переписаны правильно. Лучше всего будет просто получить прямой доступ к базе данных, скорее всего, это не повлияет так сильно, как вы думаете, и если это повлияет, вам действительно не следует кэшировать много данных на пользователя, вместо этого вы должны использовать глобальный кеш.