Session persistence

[Chris Rathman]

I'm having problems with the Session variables disappearing between
page calls and thought someone might be able to help me find the errors
of my ways. The problem surfaces in two different ways:

Randomly disappearing Session: I can run through the app and at random
places within the page requests, the Session variable just mysteriously
loses track of the primitives I placed within the Session. Are there
any known issues about when an application gets reset? And are there
ways to mitigate this problem?

Recompile causes disappearing Session: Whenever I recompile the base
modules, the application seems to reset itself, clearing out all the
session variables. This maes life difficult when I want to apply
hotfixes, since anyone that is running the application will have all
the session variables wiped out if they are logged in at the moment.

I suppose I could save off much of the Session state to the database.
But then, at the minimum, I still need at least a single reference
point of Session identity that can be accessed as the key to these
pseudo-session variables.

Any suggestions about how to maximize Session persistance would be most
appreciated.

Thanks,
Chris Rathman

 

[Brock Allen]

Randomly disappearing Session: I can run through the app and at

random places within the page requests, the Session variable just
mysteriously loses track of the primitives I placed within the
Session. Are there any known issues about when an application gets
reset? And are there ways to mitigate this problem?

You can either: 1) Use persistent session. Session can be configured to be
stored in a NT service or a DB server. This will mitigate app restarts. 2)
Don't use Session. This is my preference. There are other ways to store data
other than Session. I'd suggest either using the Data Cache or manually write
the data you need to the database. In either case, use the authenticated
user's ID/username/whatever as your coorelation identifier so you know whose
data is whose.

 

[Otis Mukinfus]

You can either: 1) Use persistent session. Session can be configured to be
stored in a NT service or a DB server. This will mitigate app restarts. 2)
Don't use Session. This is my preference. There are other ways to store data
other than Session. I'd suggest either using the Data Cache or manually write
the data you need to the database. In either case, use the authenticated
user's ID/username/whatever as your coorelation identifier so you know whose
data is whose.

If your web site is on a server farm, it's likely that the session
variables are not being passed from one server to another. Ask the
web site admin if this is a web farm. If it is the next question to
ask is if they have a session state server in the farm. If he says no
then you're screwed and will have to do as Brock suggests in his post.

I encountered this problem while developing an ASP.NET 1.1 site at
large defense contractor, who is now going after being the new CSC,
three years after ASP.NET was released. They had just begun to allow
the use of ASP.NET on their farm and didn't know they needed a session
state server.

Otis Mukinfus
http://www.otismukinfus.com
http://www.tomchilders.com

 

[Chris Rathman]

This is an app that was recently converted from asp. Thus far it's
only running on a couple of laptops for demo purposes, though it'll
move to our production server after it's thoroughly buzzed. Being a
small company, I also get to wear the web site admin hat for a while,
so blaming the admin is not productive.

Anyhow, thanks for the pointers from both of you. After reading the
replies, I figured the answer was in either creating a state server or
using SQLServer. Got frustrated with the SQLServer path, and focused
in on using the State Server option. Seems to work like a charm with
that configuration. Will have to get some further burn in time to see
if the problem has evaporated.

Thanks,
Chris Rathman.