2011-01-12 2 views
2

У меня есть веб-сайт InProc сеанса с помощью следующей реализации:Сессии и переменные сервера в Session_End

protected void Session_End(object sender, EventArgs e) 
     { 
      StreamWriter sw = null; 
      string logFile = Server.MapPath("testSessionLog.txt"); 
      sw = new StreamWriter(logFile, true); 
      sw.WriteLine("Session_End called at " + DateTime.Now); 
      try 
      { 
       //Request is not available in this context 
       if (Request.ServerVariables["Logon_User"] != null && Request.ServerVariables["Logon_User"] != "") 
       { 
        sw.WriteLine("Made it past Request.ServerVariables check"); 
       } 
      } 
      catch (Exception ex) 
      { 
       sw.Write("An error occured: " + ex.Message); 
      } 
      finally 
      { 
       sw.Close(); 
      }   
     } 

Я прочитал пару статей (1, 2) на стеке, которые идут в подробности об использовании this.Session, чтобы получить чтобы попасть в HttpSessionState. Что такое Server.MapPath() и Request.ServerVariables()? Я не могу заставить их работать в Session_End.

Я вставил этот же код кода в событие button_Click, и он запускается без проблем. Это заставляет меня думать, что это связано с Session_End.

Я устанавливаю IIS6 на recylcle один раз в минуту. Когда у меня есть открытое заседание она взрывается с: Ошибка:
Тип исключения: HttpException
Сообщение об исключении: Операция сервера недоступна в этом контексте

В окне просмотра событий он показывает, как событие 1309. Он жалуется на строку, содержащую Server.MapPath()

ответ

-2

можно получить на запрос и сервер после того, как все. Вы должны использовать HttpContext.Current.Request и HttpContext.Current.Server соответственно. Не сеанс. Там очень хорошее сравнение двух на stack.

+0

вы не можете получить доступ к HttpContext –

2

Проблема в том, что session_end не запускается из запроса. он запускается тайм-аутом на сервере, спустя много времени после обработки последнего запроса на сеансе. Таким образом, объект запроса не требуется.

Это может быть неверно, если вы вызывали Abandon на сеанс (поскольку вы это сделали в контексте запроса). Я не пробовал этого, но я подозреваю, что это тоже не сработает.

Я не знаю о MapPath - возможно, для этого требуется живой запрос.

+0

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

+0

Вы искали данные Запроса, и нет объекта Request в Session_End. Если есть вещи, которые вам нужно получить там (например, как идентификатор пользователя или что-то еще), тогда явным образом сохраняю их в сеансе: * Session ["UserId"] = _userId * – Ray

+0

Я действительно не уверен, что мы ищем , Там 12 приложений, и я не писал ни одного из них. Я просто разбираюсь в том, почему мы получаем 100 ошибок в день. Поскольку «решение», которое я опубликовал ниже, избавляется от ошибок, это «исправление». –

4

Как уже упоминалось, нет HttpContext объект для работы с при вызове Session_End, поэтому доступ к нему осуществляется. ServerVariables не имеет никакого смысла.

Для MapPath вы можете вызвать статический метод HostingEnvironment.MapPath(), который не полагается на запрос.

http://msdn.microsoft.com/en-us/library/system.web.hosting.hostingenvironment.mappath.aspx

+0

Мы используем ServerVariables для захвата UserName пользователя. Поскольку все пользователи находятся в домене, я не понимаю, как получение Logon_User не имеет смысла, когда еще есть this.Session. Если вы не говорите мне, что это. Сеанс в Session_End - это сеанс, запущенный Системой и содержащий только системную информацию. Это так? –

+0

Да. Session_End запускается в какой-то произвольной точке, которую вы не можете контролировать. Это может быть посреди ночи, когда ваш пользователь давно ушел и спящий. Важно понять, что * для доступа к HttpContext * нет, потому что событие не запускается во время некоторого запроса. –