Предотвращение окончания сеанса при изменении webroot

Question

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

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

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

Answer 1

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

Here is the information on MSDN regarding Session Mode.

Answer 2

Вы должны попробовать Sql Server session state storage

Answer 3

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

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

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

Удачи вам!