HttpContext.Current.Session?

Question

[kastaneda]

Здравствуйте. Не так давно столкнулся с непонятной проблемой на сайте — имеется asp.net mvc проект, есть single-tone класс SiteUser, через которого осуществляется вся работа с сервисами.

при успешной авторизации текущий юзер сохраняется в коллекции сессии:

1. static readonly string sessionKey = «SiteUser»;
   
2.  
   
3. public static SiteUser Create()  
   
4. {  
   
5.     SiteUser.Current = new SiteUser();  
   
6.  
   
7.     return SiteUser.Current;
   
8. }  
   
9.  
   
10. public static SiteUser Current  
    
11. {  
    
12.     get  
    
13.     {  
    
14.         if (HttpContext.Current.Session == null || HttpContext.Current.Session[sessionKey] == null)  
    
15.         {  
    
16.             throw new SiteUserAutorizationExeption();  
    
17.         }
    
18.  
    
19.         return HttpContext.Current.Session[sessionKey] as SiteUser;  
    
20.     }
    
21.     set
    
22.     {
    
23.         if (!HttpContext.Current.Session == null)
    
24.         {
    
25.             HttpContext.Current.Session[sessionKey] = value;
    
26.         }
    
27.     }  
    
28. }
    

Все работает, но иногда (sic!) срабатывает исключение по второму условию, т.е.

1. HttpContext.Current.Session[sessionKey] == null
   

— при этом сессия является активной, FormsAuthenticationTicket не просрочен.

Добавляет головоломки тот факт, что в коллекциях сессии также лежат еще, к примеру, настройки культуры, которые не обнуляются. Понятно, что нигде по коду не происходит принудительного обнуления Session[sessionKey].

Возможно кто-то сталкивался, подскажите, что можно попробовать/посмотреть/исправить?



p.s. настройки сессии в web.config:

1. <sessionState mode=«InProc» timeout=«20» />
   

update:

как подсказали в комментариях, сначала я тоже подумал, что это просто умирает сессия, и попробовал хранить продолжительности сессии и логировал изменение переменных — но SessionEnd себя так и не проявил :-( а если и проявлял, то по тому таймауту, что прописан в web.config



так вот. вчера вечером я скачал symbol-таблицы исходников .net framework, расставил брейкпоинты на изменение коллекции в недрах HttpContext (SessionStateItemCollection) и стал ждать, кликать… но баг больше не проявлялся, я решил поставить таймаут на минуту, чтобы посмотреть что происходит с сессией и коллекцией — вскрытие показало несколько вещей:

1) NULL принимают все элементы коллекции, просто настройки культуры быстро и ловко себя возвращают обратно

2) обнуление происходит при завершении сессии, что очевидно



в принципе, теперь хотя бы понятно, что удаляется не просто один элемент коллекции сессии, а вся сессия целиком. но все равно непонятно, почему она позволяет себе себя так вести, ведь в web.config указаны 20 минут

Comments

[pavelbelousov]

А точно метод Create() вызвается всегда до обращения к Current?

[kastaneda]

да, абсолютно. метод Create() вызывается в переопределенном MembershipProvider-e, в методе public override bool ValidateUser(string username, string password)

[pavelbelousov]

Может быть на IISe стоит таймаут меньше, чем в конфиге приложения?

Google выдает следующую ссылку на ваш вопрос — www.dotnetspider.com/forum/17-Session-Timeout-Problem.aspx. Там похожая на вашу проблема и приводятся несколько причин, по которым могут возникать проблемы.

[kastaneda]

ошибка проявляется в ASP.NET Development Server. посмотрел по ссылке, я уже что-то пробовал из того, что там советуют, но это не помогло (проблема топикстартета, кстати, там возникала из-за настроек хостинга).
я уже склонен предполагать, что это мб глюк машины/фреймворка. но ошибка воспроизводилась как на работе, так и дома

Answer 1

[Александр Кит]

Да, наверное, сильно не помогу, но посоветую элементарное логирование. Первое это Session_Start и Session_End методы и инкапсулировать запись/чтение/удаление значений из сессии и логировать все действия. Надеюсь кто то предложит более конструктивное решение.

Comments

[kastaneda]

спасибо за совет. ситуация несколько изменилось, добавил upd в топик

[Александр Кит]

Странно то, что "SessionEnd себя так и не проявил :-(, а если и проявлял, то по тому таймауту" и "обнуление происходит при завершении сессии, что очевидно". То есть, так понимаю, что происходит вне плановый сброс сессии без логирования. Такое мне кажется может быть только при рестарте приложения. И снова методы Application_Start и Application_End в global.asax.cs для логирования. Помню нашумевшей проблемой было, когда анти вирус проверяя файлы, на которых висит CacheDependency на рестарт (к примеру, web.config), изменял их LastWrite Аттрибут и приложение заново стартовало.

[kastaneda]

имелось ввиду, что баг не проявил себя тогда, когда я расставил «ловушки» в Session_End.
если ошибка не проявляется, то сессия работает как и должна.

«Такое мне кажется может быть только при рестарте приложения

да, но рестарта не было. была вполне себе активная сессия без рестартов и логаутов

мне подсказали, что аномальное поведение сессии можно объяснить многопоточностью — неаккуратно реализована работа с элементом сессии. сейчас класс переписан так:

1. static readonly string sessionKey = «SiteUser»;
2.  
3. private SiteUser _currentUser;
4.  
5. public static SiteUser Create()  
6. {  
7.     _currentUser = new SiteUser();  
8.     HttpContext.Current.Session[sessionKey] = _currentUser;
9.  
10.     return _currentUser;
11. }  
12.  
13. public static SiteUser Current  
14. {  
15.     get  
16.     {  
17.         if (_currentUser == null)
18.         {  
19.             throw new SiteUserAutorizationExeption();  
20.  
21.             return null;
22.         }
23.  
24.         return _currentUser;  
25.     }
26. }

[Александр Кит]

Вы создаете для одного запроса ещё дополнителные потоки? Начал сейчас искать или HttpSessionState является thread safe и как-то не ясно, то пишут, что доступ к сессии идет через ReaderWriterLocк и должен быть безопасным, то что совсем не безопасно. Сама сессия имеет пропертю IsSynchronized — всегда хотел узнать от чего тогда зависит потоко-безопасность. И ваш пример вообще удивил, как это можно из статической проперти доступаться к не статическому члену класса (Current { get { return _currentUser}})?

[kastaneda]

вы правы. это совсем неверно :-(
в исходник еще не добавлял этот кусок, скопировал сюда сразу из IM-a — слишком рано обрадовался )