What causes session to disappear?

[gnewsgroup]

In my asp.net 2.0 web application, in Web.config, I have

timeout="30", s l i d i n g E x p i r a t i o n = "true"

for the Authentication element. I suppose, this means that as long as
we don't let a 30 min elapse without making any request, the session
should stay alive, right?

But I notice that quite often, the application throws out Null
reference exception where I try to access a session variable like so:

System.NullReferenceException: Object reference not set to an instance
of an object.

Apparently, the session variable is lost.

I am sure it is way before a 30 minutes' elapse without making any
request.

Question:

1. Do we lose the session if the project gets JIT-recompiled?

2. Do we lose the session if an Exception happens?

Thank you.

 

[Steve C. Orr [MCSD, MVP, CSM, ASP Insider]]

Anytime the IIS application is restarted, all sessions are restarted too.
So yes, this would generally happen during recompilations and some major
unhandled application level exceptions.

--
I hope this helps,
Steve C. Orr,
MCSD, MVP, CSM, ASPInsider
http://SteveOrr.net
http://iPhonePlaza.net

 

[Scott Roberts]

In my asp.net 2.0 web application, in Web.config, I have

timeout="30", s l i d i n g E x p i r a t i o n = "true"

for the Authentication element. I suppose, this means that as long as
we don't let a 30 min elapse without making any request, the session
should stay alive, right?

But I notice that quite often, the application throws out Null
reference exception where I try to access a session variable like so:

System.NullReferenceException: Object reference not set to an instance
of an object.

Apparently, the session variable is lost.

I am sure it is way before a 30 minutes' elapse without making any
request.

Question:

1. Do we lose the session if the project gets JIT-recompiled?

2. Do we lose the session if an Exception happens?

Thank you.

I think the answer depends on the session-state "Mode" of your web app.
Assuming it's "in-proc" (the default) then modifying web.config or a DLL in
the "bin" directory will do it. As will restarting the application pool
(either manually, or automatically due to memory limits, cpu utilization,
etc.).

You might try switching to StateServer or SQLServer mode, but you will need
to ensure that you only put value types and serializable objects into the
session if you do that.

In general, you should always verify the existence of a session object
before trying to use it - and handle the case where it doesn't exist.

 

[Juan T. Llibre]

An application domain will unload (causing loss of session variables
unless session state is maintained with State Server or SQL Server),
when any one of the following occurs:

a. Machine.Config, Web.Config or Global.asax are modified
b. The bin directory or any of its contents is/are modified
c. The App_Code directory contents changes
d. The number of re-compilations (aspx, ascx or asax) exceeds the limit specified by the
<compilation numRecompilesBeforeAppRestart=/> setting in machine.config or web.config
(by default this is set to 15)
e. The physical path of the virtual directory is modified
f. The CAS policy is modified
g. A web service is restarted
h. (2.0 only) Application Sub-Directories are deleted
i. Any of a number of configurable App Pool recycling reasons occurs

This should cover most scenarios.

 

[zhaojk]

Anytime the IIS application is restarted, all sessions are restarted too.
So yes, this would generally happen during recompilations and some major
unhandled application level exceptions.

First of all, Steve, thank you so much, and I just found your
marvelous ExportPanel yesterday and have put it into my code. Really
nice and neat. Thanks for sharing your wonderful work for free.

Now back to this thread topic. I also notice that the session does
not always disappear when an exception happens. Is it possible to
predict what type of exception will cause the session to disappear?

 

[gnewsgroup]

Anytime the IIS application is restarted, all sessions are restarted too.
So yes, this would generally happen during recompilations and some major
unhandled application level exceptions.

Is it possible to predict what type of exception will cause the
session to disappear? Or does M$ has a list of Exception types that
will cause session to disappear?

BTW, I found your cool ExportPanel just yesterday and have put it into
my web application. Really nice and neat. Thanks for sharing your
wonderful work for free.

 

[gnewsgroup]

I think the answer depends on the session-state "Mode" of your web app.
Assuming it's "in-proc" (the default) then modifying web.config or a DLL in
the "bin" directory will do it. As will restarting the application pool
(either manually, or automatically due to memory limits, cpu utilization,
etc.).

You might try switching to StateServer or SQLServer mode, but you will need
to ensure that you only put value types and serializable objects into the
session if you do that.

In general, you should always verify the existence of a session object
before trying to use it - and handle the case where it doesn't exist.

That brings up a question which I have always been wondering. So you
suggest that we should always do something like:

if ( Session.Contents["MySessionVariable"] != null)
{
// Do things with MySessionVariable
}
else
{
// Do something else, maybe including logout a user if some
critical
// session variables such as "UserName" is missing.
}

before we use that session variable? That's a lot of if-else's if we
use quite many session variables.

 

[gnewsgroup]

An application domain will unload (causing loss of session variables
unless session state is maintained with State Server or SQL Server),
when any one of the following occurs:

a. Machine.Config, Web.Config or Global.asax are modified
b. The bin directory or any of its contents is/are modified
c. The App_Code directory contents changes
d. The number of re-compilations (aspx, ascx or asax) exceeds the limit specified by the
<compilation numRecompilesBeforeAppRestart=/> setting in machine.config or web.config
(by default this is set to 15)
e. The physical path of the virtual directory is modified
f. The CAS policy is modified
g. A web service is restarted
h. (2.0 only) Application Sub-Directories are deleted
i. Any of a number of configurable App Pool recycling reasons occurs

This should cover most scenarios.

Juan T. Llibre, asp.net MVP
asp.net faq :http://asp.net.do/faq/
foros de asp.net, en español :http://asp.net.do/foros/

Fantastic, I never know about this. Your list of situations are
certainly enough to explain why my sessions are mysteriously missing.
Thank you.

 

[John Saunders [MVP]]

I think the answer depends on the session-state "Mode" of your web app.
Assuming it's "in-proc" (the default) then modifying web.config or a DLL
in
the "bin" directory will do it. As will restarting the application pool
(either manually, or automatically due to memory limits, cpu utilization,
etc.).

You might try switching to StateServer or SQLServer mode, but you will
need
to ensure that you only put value types and serializable objects into the
session if you do that.

In general, you should always verify the existence of a session object
before trying to use it - and handle the case where it doesn't exist.

That brings up a question which I have always been wondering. So you
suggest that we should always do something like:

if ( Session.Contents["MySessionVariable"] != null)
{
// Do things with MySessionVariable
}
else
{
// Do something else, maybe including logout a user if some
critical
// session variables such as "UserName" is missing.
}

before we use that session variable? That's a lot of if-else's if we
use quite many session variables.

Some suggestions are:

1) Don't use so many Session variables. Instead of separate variables, put a
related set of session variables into a class, and store the class in
Session
2) Encapsulate your references to Session variables into properties:

public int IntInSession
{
get
{
if (Session["IntInSession"] == null)
{
// get the default or current value from wherever
Session["IntInSession"] = valueYouGot;
}
return (int) Session["IntInSession"];
}
set {Session["IntInSession"] = value;}
}

If you need access to these variables on many pages, move the properties to
a base page and inherit from it. Alternately, move them into a separate
class, create an instance of that class whenever you need access, and use
_instance.IntInSession to reference them. The properties would have to
change to use HttpContext.Current.Session instead of "Session".