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

Question

Я прочитал две статьи MSDN о режимах состояния сеанса в ASP .Net. 1 и 2.

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

Может ли кто-нибудь объяснить мне, почему он проигнорирует событие Session_OnEnd для режимов StateServer или SQLServer?

Answer 1

Я считаю, что производительность является основной проблемой. Во всех, кроме режима InProc, есть несколько веб-серверов, отвечающих на запросы, и 1 сервер (может быть кластеризованным SQL), обрабатывающий состояние.

Теперь, кто будет отвечать за обработку таймаута? Это должен быть государственный сервер, но мы хотим как можно меньше обременять этот сервер. И потребовалось бы, чтобы сервер состояния выводил данные на (случайный) веб-сервер, поскольку все остальное оно опрошено. Я сомневаюсь, что в настоящее время на государственном сервере даже хранится список веб-серверов, им это не нужно. Итак, для события SeesionEnd необходимо добавить сложную систему для администрирования мониторинга WebServers.
Добавьте к этому сложность отслеживания того, действительно ли выбранный сервер действительно завершил событие, и все это становится очень непривлекательным.

Answer 2

Режимы StateServer и SQL Server работают в конфигурации, где они могут обслуживать N количество клиентов в сценарии балансировки нагрузки и должны будут поддерживать этот список и отправлять сообщения через процесс/машину, чтобы сигнализировать Session_OnEnd. InProcess знает, что сеанс управляется в том же процессе, что и приложение, поэтому отправка обратного вызова в один прослушиватель является простой и неотъемлемой частью .NET Framework. Если вам это не нравится, вы можете написать свой собственный обработчик, но помните о cavaets.