views:

153

answers:

3

I would need to access to Session variables on Session_End event in global.asax.cs, but HttpContext.Current is null, so none of the session varables are accessible.

a) Can I access user session somehow differently, or

b) Is there any other event jut before Session_End, I could access user's session variables?

A: 

Unless you are using Session_End for the specific purpose of taking actions when a session times out, relying on Session_End is not a good idea.

I don't believe there is any reliable way to capture the end of a user's session (for example when they close the browser).

Phil Sandler
This is not necessarily true. If you are using InProc sessions, when a session has not had activity in [timeoutvalue] minutes, it will fire. If you are using stored sessions, this doesn't happen.
womp
i think relying on session_end would be the only way if you need an accurate global list of active user sessions
the berserker
A: 

What are you trying to do?

There is no event just preceeding Session_End which would you can use to access the Session object.

If you stored a action timestamp relating to the last time the Session object was used, and then checked that, you could get some idea of when it should end.
(Based on your IIS settings / configuration). However the act of accessing it would prolong the life of the Session object.

Of course you'd need to check this somehow, either by using a hidden Ajax postback which fires an event or something similiar.

But really I wouldn't advise this. What are you trying to do that you need this?

Bravax
I am trying to keep the global list of all users with active session. So therefore I need to clean user's session when it ends (let's consider, that user didn't log-off, he or she has just closed the browser), so I need to delete this user from global hashtable, by some session GUID. As far as I know, SessionID can be different for different requests, so I can't use that one
the berserker
+4  A: 

I use Session_End and Session is available directly without requiring HttpContext.Current.

Ray
Yes. System.Web.SessionState.HttpSessionState is the one I should use instead of HttpContext.Current. Thanx
the berserker