Управление тайм-аутом сеанса в ASP.NET

У меня есть веб-приложение ASP.NET 2.0, которое обращается к нескольким веб-службам ASP.NET 2.0. Оба используют сеансы ASP.NET для сохранения данных сеанса.

Чтобы предупредить пользователя о тайм-аутах сеанса приложения, я использую модифицированную версию Элемент управления тайм-аутом Трэвиса Коллинза, чтобы отобразить ModalPopupExtender с заголовком« Срок действия вашего сеанса истекает »и кнопки« Оставаться в системе »и« Выйти ». При нажатии «Оставаться в системе» он выполняет обратный вызов пустому методу, который сбрасывает таймер сеанса (я считаю, потому что каждый HttpRequest вызывает вызов ResetItemTimeout).

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

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


web-applications asp.net session timeout web-services
person Sam    schedule 17.02.2010    source источник
comment
Это веб-приложение или браузер .Net (из JavaScript) вызывает веб-службы?   -  person Ope    schedule 17.02.2010
comment
Веб-приложение .net   -  person Sam    schedule 18.02.2010

Ответы (3)


arrow_upward
0
arrow_downward

Я не уверен, что понимаю. Вы говорите, что вызов пустого метода в веб-сервисе не сбрасывает таймер сеанса?

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

person womp    schedule 17.02.2010
comment
Ваш 1-й: я предполагаю, что вызов пустого метода сбросит таймер; проблема в том, где вызвать метод. Ваш второй: я не думаю, что .net может совместно использовать файлы cookie, потому что первый находится между браузером и веб-приложением, а второй - между веб-приложением и службой. - person Sam; 18.02.2010

arrow_upward
0
arrow_downward

Когда приложение .Net вызывает веб-службу, именно веб-приложение .Net является клиентом и владеет сеансом. Сеанс веб-службы - в лучшем случае - специфичен для веб-приложения .Net, а не для пользователя с браузером, который был клиентом веб-приложения.

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

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

person Ope    schedule 18.02.2010
comment
Веб-службы могут сохранять состояние сеанса с помощью файлов cookie: msdn.microsoft.com/en-us/library/ В этом случае каждый сеанс веб-приложения является клиентом Интернета. услуга. - person Sam; 19.02.2010
comment
Хорошо, извините, что сомневаюсь в вас. Я просто предположил, что если вы знаете, как это сделать, вы бы этого не сделали: этот тип распространения файлов cookie / сеанса выглядит как взлом. Полностью противоречит принципам SOA. Но, возможно, у вас есть веские причины для этого ... По сути, таймер сеанса сбрасывается каждый раз, когда делается запрос, поэтому для вызова веб-службы вы можете просто подключиться к любому событию, которое запускается каждый раз при выполнении запроса. . Например. BeginRequest в приложении (в Global.asax.cs Application_Start добавьте this.BeginRequest + = your_event_for_web_service_call) - person Ope; 20.02.2010

arrow_upward
-1
arrow_downward

Если вы собираетесь более или менее автоматически продлевать тайм-аут, почему бы просто не установить его очень высоко для начала? ЦЕЛОВАТЬ. и избавьте себя от лишних хлопот с написанием кода там, где в этом нет необходимости.

person Bryan    schedule 17.02.2010
comment
Чем больше тайм-аут, тем больше сеансов будет храниться в памяти и тем больше ресурсов потребуется серверу. Чтобы гарантировать время ожидания сеанса службы не может быть истекло до того, как сеанс приложения потребует бесконечного времени ожидания и, следовательно, бесконечных ресурсов сервера. Если я отключаю неактивные сеансы по таймауту, мне нужны только ресурсы, пропорциональные моей пользовательской нагрузке. - person Sam; 18.02.2010