Sharing resources between web requests?

Question

Is there a standard way, in ASP.Net, to share resources between web requests?

This is my problem:

• There is a web service I need to query from the code behind of several pages
• This web service only allows one logged in session at a time
• If you log in twice, the first session is invalidated
• Sessions are stored as strings, and expire every 45 minutes, at which point I must re-authenticate
• Two queries can run at the same time as long as they are using the same session

That being said, what would be the best way to have this session available to multiple pages / requests at the same time? And how can I make sure that once the session expires, that, after a re-login, the new session is shared?

This is all run on a single server.

Answer 1

I would wrap the whole web-service in a service-like class and use an IoC like ninject to manage the instance of that service. You should then come up with a custom scope in ninject to invalidate the expired session.

Then in your asp .net, every request that needs to access that web-service resource should ask ninject to return an instance of the service you created. ninject then will manage to always return the same instance as long as the session is valid (given that you've got the custom scoping right).

Answer 2

I think what you're looking for is the "session" variables for keeping your data trough the session.

http://msdn.microsoft.com/en-us/library/aa287606(v=vs.71).aspx

-- edit --- The Application object of .net is what you're looking for, it applies since 3.0: msdn.microsoft.com/en-us/library/ms178594(v=vs.85).ASPX

With that you'll save state variables with your app running in the server.

Answer 3

If your site runs on a single server, you could store the service's session string in Cache , which has a maximum lifetime and visibility that corresponds to the server process, rather than to one of your client's Sessions.

It's easy then for any part of your code to get hold of the current session information, and establish a new session if it isn't already in cache. If you arrange the cache lifetime to be slightly shorter than the session lifetime of the service, then you'll never see the session reject you for having expired - your own cached copy will always expire first.