Предотвратить конец сеанса при изменении webroot

Question

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

Мой вопрос - есть ли что-нибудь, чтобы предотвратить это, или мне просто нужно с этим жить? Потратил последние 3 часа на изумление и не могу найти решение.

Заранее спасибо.

Answer 1

Решение состоит в том, чтобы использовать другой режим сеанса;Вы используете «InProc», что означает, что сеанс хранится в том же пространстве приложения, что и ваше приложение.Вы можете использовать «StateServer» или «SQLServer», однако для этого, вероятно, потребуются изменения приложения (и дополнительная настройка; для StateServer потребуется запуск отдельной службы на IIS Server, а для SQLServer потребуется база данных для хранения информации).Все, что вы храните в сеансе, должно быть сериализуемым.

Вот информация на MSDN относительно режима сеанса .

Answer 2

Вы должны попробовать Sql Server Сеанс состояния хранения

Answer 3

Если ваш вопрос касается поддержания работоспособности вашего сервера в режиме 24x7 без каких-либо помех для пользователей (потеря сеанса / простои системы и т. Д.), То он включает следующие шаги:

1. Вам следует настроитьприложение для хранения ваших сеансов в БД
2. Вам нужно настроить более одного сервера приложений в качестве стратегии восстановления после отказа
3. Для динамической маршрутизации запросов на один из этих серверов вам потребуется загрузкабалансировщик
4. Теперь, когда вы хотите развернуть следующую версию выпуска в реальном времени в приложении.серверы говорят S1 и S2, следуйте шагам ниже: [4.1.] Измените свою конфигурацию балансировщика нагрузки так, чтобы она не перенаправляла запросы на S1.[4.2.] Разверните приложения на S1 [4.3.] Измените конфигурацию балансировщика нагрузки, включите S1 и на этот раз исключите S2.(При этом все последующие запросы будут попадать в S1, получая информацию о сеансе. Из общей базы данных, к которой подключены S1 и S2) [4.4.] Повторите вышеуказанные шаги, как требуется.

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

Удачи!