Losing Session state

[Arthur Dent]

Hello all, I have some issue which is driving me crazy in testing my site...

Every now and then, the session variables in my site all get cleared out. I
assume this is because of something causing the AppPool to recycle.
The thing that really throws a wrench into all this though, is that after
the app recycles, User.Identity.IsAuthenticated is still returning true!
So despite the fact that the session and all its information is gone, and
effectively destroyed, the app is still reporting that the user is logged
in.
How can I either get it to stop recycling, or to sign the user out along
with the recycle?????

Thanks in advance,
- Arthur Dent.

 

[Teemu Keiski]

Hi,

if your application uses InProc session state, that indeed is wiped out when
application pool recycled. And especually in ASP.NET 2.0 or better apppool /
application restarts can occur quite easily (a few changes to files, change
in web.config, adding new dlls to bin etc etc). Therefore it's best to use
out-of-process session state modes such as SQL Server or State Server

http://msdn.microsoft.com/en-us/library/ms178586.aspx

 

[Peter Bromberg [C# MVP]]

Depending on what type of authentication your site uses (Forms auth, for
example), this does not depend on Session State at all. Forms auth has a
forms ticket in the form of a cookie that is read by the forms
authentication provider on each page request. If the cookie is there, you
are authenticated. Nothing to do with Session at all.
Peter

 

[Mark Fitzpatrick]

You can't get it to automatically sign the user out since it is a global
action. The user will still be authenticated because the authentication
information is completely separate from the session state and is stored
client-side in an authentication cookie.

You could create a class that helps you control access to session variables.
This way if, for example, the session variable is null you can test for it
and then perform whatever action you need in order to reload that variable.
This is good practice because session variables can be lost for a myriad of
reasons and always depending on them to have a value can lead into problems
just like this.

You also don't want to stop the application from recycling. Instead, look at
why it's recycling. If you're storing large objects in the session state,
it's recycling because it's out of memory or there is a serious fault that
has caused the app to crash and recycle. Before you try to alter this
behavior, examine the data you are storing in the session and determine if
you have anything rather large in there and figure out how much memory that
item is using given the number of times it's being replicated by the user
count. Also make sure that any data access functions you have close their
connections to the db as soon as possible so the connection can be returned
to the pool. An app can recycle when it runs out of connections in the pool
so this can be critical.

Hope this helps,
Mark Fitzpatrick
Microsoft MVP - Expression

 

[Moe Sisko]

.. or to sign the user out along with the recycle?????

You might find this article helpful :

http://www.abstraction.net/content/...on and authentication timeouts in asp.net.htm

So, in the Session_Start event, once a new session is detected, you could
call :

FormsAuthentication.SignOut( ); to logout, if you are using forms
authentication.

Also note that the code shown in the Session_Start event has a potential
problem - if a user was on the Login page when session expired, it will
redirect back to the Login page, which is not necessary. So you could check
the page of the current request, and not perform the redirect if you are
already on the login page.

HTH,
Moe

 

[Arthur Dent]

This seems like the best approach. I'm kind of working this direction now,
but your post helped clarify and clean up the logic I was using.
The article also is a very good discussion.

Thanks for the help!! CheerZ