Hi Keith,

Ok, thanks. We'll fold this into our methodology as we iron out this issue.

Bill

>Bill,
>
>This is a common issue with session state - especially when a third-party host is being used.
>
>The session cache is not intended to be used to store login and authentication data. It is designed as a *very* temporary cache to hold things like datasets that are expensive to retreive from a database server on each round trip.
>
>The best way to avoid these problems is to use a cookie to store the login information and a database table to cache the rest of the user's personalized data. Hash the login information and use that as the primary key for the table and also include a "LastAccessedDateTime" column in the table so that it can be flushed periodicaly.
>
>The best way to implement this is to have a separate class that encapsulates the personalized data. In this class, use the session state as the primary storage medium, use the above-mentioned database table as the secondary storage medium, and use the place where the data originated as the fall-back.
>
>This method has a side benefit of tracking who and when the web application is accessed. It can be expanded to track individual page hits, server response times, HTTP request header data, etc...
>
>>We have an ASP.NET application running on a web hosting server so we exercise no control over the server.
>>
>>When a user logs in to the application, it creates an object in which is stored certain data items. This object is maintained in the Session State. The first thing a page does when loaded is to check for this object in the Session State. If the object exists it is accessed from Session and the user is allowed to continue. If the object is not found in Session, the user is redirected to the Login page under assumption that the user's session had timed out or they had tried to hit the page without logging in.
>>
>>For testing purposes, the Timeout in Web.config was set to 20 minutes. We are seeing random times when the user is redirected to the Login page long before the timeout should have expired. It seems to have no pattern to it. Development was done on this application on two separate machines, neither of which exhibited this behavior during development and testing. At this point we do not know whether it is a timing out issue or if the object in Session State is being removed/destroyed for some unknown reason.
>>
>>Has anyone seen this kind of behavior and what could be the cause and cure for it?
>>
>>Thanks,
>>Bill