I guess I can always go the extra mile and save state data elsewhere. Nevertheless, I
still need to determine when the postback occurs after the session expired.
I noticed that on a Session_Start() event, the Request.HttpMethod property is set to
"GET". After that, when the user takes an action on the web page which causes a post back
to the server, the Request.HttpMethod property is then set to "POST".
After a session timeout, if the user once more cause a post back, the Session_Start()
event is fired and this tim Request.HttpMethod instead of being set to GET, is not set
to POST.
Would a check on "POST" in a Session_Start() event be enough to detect a post-session
timout request?
On Mon, 24 Oct 2005 12:02:49 +0200, "Lars Netzel" <ui****@adf.se> wrote:
There are alternatives when storing the Session data... this will of course
be a little tradeoff on the Performance but you have store the session
information in other places...
If possible and the page is not too big already, then why not save the dataa
whithin the viewstate of the page?
Or if you really need to store it on the server.. Read about storing Session
data in a SQL database or thru the ASP.NET State Service
/Lars