Session state being lost

[Jacob Anderson]

Hello,

I have a web application running in two configurations:

1. On my local machine running in debug and release mode
2. On a shared, hosted, machine in release mode

On my local machine, the app never loses its session
state (which is how I manage the login state for the app).

On the shared machine, the session state seems to be
reset intermittently. I see this manifested as a user
being "kicked back" to the login screen yet being able to
go "back" to the previous protected page and still have
the session available.

My application stores some data in the session to
identify the user that is currently logged into the app.
I detect when the user is not logged in by doing the
following:

1. Check if the session is new or not
2. Check for the existence of the login state

So I "think" the session is being marked as 'new' on the
shared server, but the login state object is still in the
session.

My configuration on both types of configuration is:

Session mode=InProc
Sesion memory = 1 GB (on the shared server)
ASP.NET version=1.1

Does anyone know what things I should look at on the
shared server in terms of configuration or what-not? I
tried using "forms" based authentication, but could not
ever get it to work properly for the two types of logins
I need to support.

Thanks

-- Jacob Anderson
(e-mail address removed)

 

[Dmitry Andreev]

There some virus scanners, what touch web.config or some other important
app files , and force application restart and session lost.

 

[William LaMartin]

I am having similar problems at a shared hosting site and have not as yet
found a solution.

Where does one set the Session Memory?

 

[William LaMartin]

But setting SessionState to SQLServer is not really an option for most
shared hosting sites.

 

[Jacob Anderson]

We didn't have problems with the session state until we reached a
certain threshold of activity. On the shared server, though, we are
equally at the whim of other applications running on the same machine
(who will chew up memory that our app needs).

Could be that the next solution is to use a dedicated server and the
session state server (not the SQL server yet). The session state server
is likely going to be faster than the SQL server (less connection
overhead?).

Thanks!

=======================================
Jacob W Anderson
Beyond Ordinary Software Solutions
http://www.beyond-ordinary.com
(e-mail address removed)
=======================================

 

[Rajesh.V]

Put session in an outofproc server. Sql server. Session problems are very
common with asp.net all versions. It goes away the moment u use sql server.
Maybe ms wants to force people to buy it.

 

[William LaMartin]

If the cookie limit is 4 KB, then this would work for some applications but
not for one where I need to store a small 20 KB JPEG file as a session
variable to be able to response.binary write it to another aspx page.

I think it is really a local situation on a particular shared server that is
causing the problem. I have no problem with session variables in other
situations using the same settings that I have control over. The web host
says they are researching the problem, but no solution arrives.

 

[Rajesh.V]

Ok William then why not build a custom solution, which will store the data
to be persisted in a cookie which will take uptill 4kb. Then u get out of
this session ruckus.

 

[Jacob Anderson]

Eureka! In IIS6, the ASP.NET process model has changed significantly!
Now, they use process pooling to manage the load on the server. What
this means for us, is that IIS6 will choose a new process, i.e.
AppDomain, for each request in an attempt to load balance the "internal
state" of the application.

Well, we have found that the session bag is not marshalling across the
processes in the pool, which means the session is killed each time a new
process is selected from the pool! Yikes.

You can fix this by having your ISP set the process pool size to '1' in
the application's configuration. Unfortunately, there is NO way for you
to change this in the machine.config or web.config files.

We made this change and now nobody gets kicked out of the app. This
might be a bug in IIS6 ??

-- Jake

=======================================
Jacob W Anderson
Beyond Ordinary Software Solutions
http://www.beyond-ordinary.com
(e-mail address removed)
=======================================