Session State stateserver or Sql Server

[tshad]

I have been using the default session state (InProc) and have found that I
have been loosing my information after a period of time (normally 20
minutes).

Is there anyway to find out how much more time I have on a session?

If I do a refresh, does reset the session clock?

Do you have have to go to another page to reset the session timeout or will
a postback also do it? This is important as we have a few pages that a user
will stay on where he will be doing all kinds of submits that will just do
Postbacks (so the page doesn't change). This could be a problem if all of a
sudden the timeout period comes up and the user has not left the page. All
of a sudden, I get an error that says the session variable is blank.

I am thinking of switching ot State Server or Sql Server mode, but am not
sure of the drawbacks. Most of the books give a small idea of the different
modes but not much on the pros and cons.

One question is - does my code still work the same as far as setting and
reading session variables?

Thanks,

Tom

 

[Craig Deelsnyder]

I have been using the default session state (InProc) and have found that I
have been loosing my information after a period of time (normally 20
minutes).

Is there anyway to find out how much more time I have on a session?

If I do a refresh, does reset the session clock?

Do you have have to go to another page to reset the session timeout or will
a postback also do it? This is important as we have a few pages that a user
will stay on where he will be doing all kinds of submits that will just do
Postbacks (so the page doesn't change). This could be a problem if all of a
sudden the timeout period comes up and the user has not left the page. All
of a sudden, I get an error that says the session variable is blank.

I am thinking of switching ot State Server or Sql Server mode, but am not
sure of the drawbacks. Most of the books give a small idea of the different
modes but not much on the pros and cons.

One question is - does my code still work the same as far as setting and
reading session variables?

Thanks,

Tom

Any requests cause the Session to reset its counter; i.e. it is a
sliding expiration. If you wanted to know the amount of time left (for
some reason after knowing it does reset its timer), you'd have to set
your own Session variable to hold the current time, set it when done
processing and response is set to client. Then you'd have to do the
math on the next request....but not much use to me, unless you want to
know how close you came to timing out...

SqlServer and StateServer are useful for when you want to persist the
session across webserver restarts; it stores the Session info on another
server (or out of process). There's no discernible difference in how
you would call variables themselves...

 

[Robbe Morris [C# MVP]]

StateServer on a single box or a web farm with session affinity
will get rid of your periodic session loss with InProc.

Read these, they'll be helpful

ASP.NET Session FAQ

http://www.eggheadcafe.com/articles/20021016.asp

More info on how StateServer might help

http://www.eggheadcafe.com/articles/20030416.asp

Optional software to better manage InProc
session state outside of ASP.NET in a web farm.

http://www.eggheadcafe.com/articles/scaleout_server.asp

--
2004 and 2005 Microsoft MVP C#
Robbe Morris
http://www.masterado.net

Earn $$$ money answering .NET Framework
messageboard posts at EggHeadCafe.com.
http://www.eggheadcafe.com/forums/merit.asp

 

[tshad]

Any requests cause the Session to reset its counter; i.e. it is a
sliding expiration.

Well, that would make sense except that I am in development mode and am
working on a page at a time and making many changes. Then I usually just do
a refresh or go back a page and hit one of my buttons to rerun the page. I
am doing this every couple of minutes or so. But after about 15-20 minutes
the session variables are gone. If each request would reset the counter,
why am I losing my session variables?

If you wanted to know the amount of time left (for
some reason after knowing it does reset its timer), you'd have to set
your own Session variable to hold the current time, set it when done
processing and response is set to client. Then you'd have to do the
math on the next request....but not much use to me, unless you want to
know how close you came to timing out...

Mainly for testing purposes.

SqlServer and StateServer are useful for when you want to persist the
session across webserver restarts;

Does this include the worker process recycles? Or does it not do these
recycles in these modes?

Tom

 

[tshad]

StateServer on a single box or a web farm with session affinity
will get rid of your periodic session loss with InProc.

Read these, they'll be helpful

ASP.NET Session FAQ

http://www.eggheadcafe.com/articles/20021016.asp

That answered a lot of questions ad I have already changed to "stateServer"
mode and it seems to work fine. I will test it out more tomorrow.

One question that I have is if I am using stateServer, does the "worker
process recycles" still happen? If so, how does this affect my session?
The articles say that you don't lose the session variables during the
recycles.

Also, if you the session times out (but you don't lose your sessionID -
which is what the articles said until the browser closes), do you lose your
session variables at this time when using "stateServer" mode?

Thanks,

Tom

 

[Juan T. Llibre]

Hi, Tshad.

I see you've made some progress since the suggestion
to switch to State Server. Congratulations!

re:

One question that I have is if I am using stateServer,
does the "worker process recycles" still happen?

Yes, they do.

All ASP.NET worker processes you may have running
will get recycled depending on the way you configure them.

State Server runs in a *different* process which doesn't get recycled
until you reboot the computer where the application is running,
and that's why the session variables aren't lost when the ASP.NET
worker process is recycled.

The two processes have independent lives, although they work together.

re:

If so, how does this affect my session?

Your session variables continue to exist until the session times out
or until the box is rebooted.

 

[Robbe Morris [C# MVP]]

The browser still keeps the session id. However, the server
had already dropped the session. So, if the browser
sends the request with an invalid key, a new session would
be created.

Yes, if you use StateServer, session won't be lost when
the process recycles. Session state is no longer held
in that process. It has its own windows service.

--
2004 and 2005 Microsoft MVP C#
Robbe Morris
http://www.masterado.net

Earn $$$ money answering .NET Framework
messageboard posts at EggHeadCafe.com.
http://www.eggheadcafe.com/forums/merit.asp

 

[tshad]

Hi, Tshad.

I see you've made some progress since the suggestion
to switch to State Server. Congratulations!

Thanks - I will be checking it out today, but it seems to have solved the
problem.

re:

Yes, they do.

But what do they do?

If the worker process recycles at a different time then the session
timeouts - what is it doing and what is the point if the session is still
live?

All ASP.NET worker processes you may have running
will get recycled depending on the way you configure them.

Are you talking about the Application Pools Properties?

There are various properties there that I am not sure what to do with.

The only thing on the Recycle tab that I have checked is "Recycle work
processes (in minutes)" and it is set to 1740. That is 29 hours - this
obviously was not what was clearing my session variables. None of the
others (Number of requests, specific time, memory) are checked.

I assume that the Idle timeout might have been cause it (but it doesn't say
recycle - it says shutdown the process. Would this clear the session
variables?

If this is supposed to release the resources - wouldn't this cause the
session a problem, even if the session variables are there?

State Server runs in a *different* process which doesn't get recycled
until you reboot the computer where the application is running,
and that's why the session variables aren't lost when the ASP.NET
worker process is recycled.

Wait.

I thought the session still gets recycled if in StateServer mode - you just
don't lose the session variables.

The two processes have independent lives, although they work together.

re:

Your session variables continue to exist until the session times out
or until the box is rebooted.

But if the recycling happens and you lose your resources - how does the
session still work?

Tom

 

[tshad]

The browser still keeps the session id. However, the server
had already dropped the session. So, if the browser
sends the request with an invalid key, a new session would
be created.

Very confusing.

Trying to get my brain around the recycling verses the session dropping.

When the session is dropped - you lose your session variables?

So when you send a request with an invalid key - you get a new key, but all
the variables are gone?

Would the Session_Start event get fired at this point - since it has a new
key (and a new session)?

How do you know the session has been dropped? Is there an event fired to
indicate this? I know that the Session_End event doesn't happen in
StateServer or SqlState - how do you know that the State is still active?
Should you look at something in the Page_Load event to make sure it is still
active?

Thanks,

Tom

Yes, if you use StateServer, session won't be lost when
the process recycles. Session state is no longer held
in that process. It has its own windows service.

 

[Juan T. Llibre]

There's a lot of questions in your post,
but only is really critical, so I'll address it.

re:

I thought the session still gets recycled if in StateServer mode - you just don't lose
the session variables.

The session doen't get recycled when you use State Server.
The *ASP.NET worker process* gets recycled.

The whole purpose of using State Server is to store the session variables
in a Windows service ( the State Server ) which does *not* recycle
when the ASP.NET worker process recycles, which means that
your session variables ( stored in the State Server) don't get lost.

I hope that makes those concepts clearer.

 

[tshad]

There's a lot of questions in your post,
but only is really critical, so I'll address it.

re:

The session doen't get recycled when you use State Server.
The *ASP.NET worker process* gets recycled.

The whole purpose of using State Server is to store the session variables
in a Windows service ( the State Server ) which does *not* recycle
when the ASP.NET worker process recycles, which means that
your session variables ( stored in the State Server) don't get lost.

Right. But what does the worker process recycling do? Does it affect the
session?

Tom