views:

405

answers:

3

I have a ASP.NET 2.0 Web Application talking to multiple ASP.NET 2.0 Web Services. Both use ASP.NET Sessions to persist session data.

To warn the user about session timeouts of the app, I use a modified version of Travis Collins's Timeout Control to show a ModalPopupExtender titled 'Your session is about to expire' and buttons 'Stay Logged In' and 'Logout'. On clicking 'Stay Logged In' it makes a callback to an empty method, which resets the session timer (I believe because each HttpRequest causes a call to ResetItemTimeout).

To prevent the session in the services timing out before the one in app, I set their timeouts to be longer, and planned to call an empty method on them whenever the session timer is reset in the app. However, there is no Session-State Event for the timer being reset.

Do I have to override ResetItemTimeout? How do I do this? Or is there another way to acheive my aim (e.g. keep the service session alive whilst the app service is alive)? I'm considering extending my timeout control to send heartbeats via the app (like Tim Mackey's idea).

A: 

I'm not sure I follow. Are you saying that calling an empty method on the webservice does not reset the session timer?

Additionally, this seems like a lot of overhead. Why not set the web application and the web services to use the same session cookies?

womp
Your 1st: I'm assuming calling an empty method would reset the timer; the problem is where to call the method.Your 2nd: I don't think .net could share the cookies, because the first sits between the browser and the web app, whilst the second sits between the web app and the service.
Sam
+1  A: 

If you're going to more or less automatically extend the timeout, why not just set it very high to begin with? K.I.S.S. and save yourself the hassle of writing code where you don't really need to.

Bryan
The bigger the timeout, the more sessions are going to be kept in memory, and the more resources the server will need. To *guarantee* the service session cannot timeout before the app session would require an infinite timeout, and therefore infinite server resources.If I timeout the inactive sessions, then I only need resources proportional to my user load.
Sam
A: 

When the .Net application is calling the web service, it is the .Net web application that is the client and who owns the session. The session of the web service is - in the best case - specific to the .Net web application, not to the user with the browser, who was the client of the Web Application.

I think the default case is even that the session starts every time web service call is made (web service calls do not save cookies, which are required for session state), so it does not store anything between calls. But I did not test this now. There are several ways of making the call and I think some of them store cookies and some don't.

But in any case: In your scenario, there is really no reason to use session in the web services: For web services, there is only one client (the web app), so you could as well use Application state, if you need to cache data or something.

Ope
Web services *can* save session state using cookies:http://msdn.microsoft.com/en-us/library/system.web.services.webmethodattribute.enablesession(VS.80).aspxIn this case, *each session* of the web application is a client of the web service.
Sam
OK, sorry for doubting you. I just assumed that if you know how to do this, you would not do it: this type of propagating cookies/session just seems like such a hack. Completely against SOA principles.But perhaps you have good reasons for doing this then...Basically, the session timer is reset every time a request is made, so to make your web service call, you could just hook into any event that fires every time the request is made. E.g. BeginRequest in the application (in Global.asax.cs, Application_Start add this.BeginRequest += your_event_for_web_service_call)
Ope