I've just run into something unexpected. I'm caching an expensive resource in the ApplicationContext.LocalContext.
I don't want to transfer this between server and client.
I have some server-side code that checks if the item is in the ApplicationContext.LocalContext and if not, makes the expense and places in the local context. I expected this item to remain in the LocalContext for subsequent calls to the Data Portal from the Silverlight client, but this is not the case.
Is my expectation of it wrong?
LocalConext exists for the length of a given user interaction.
On a smart client a user interaction is the entire length of the app's runtime.
But on a web server a user interaction is the entire length of each single, individual call. Typically measured in milliseconds.
LocalContext is not a replacement for Session, which is probably what you are actually looking for.
Thanks for that Rocky
I have it wrong then, and what your saying does make sense: Statelessness of Http, WCF Per-Call activation, etc. -> all these things all mean "we are going let go of those resources when we're done with that request and rebuild it from scratch for the next". The contrast is a data portal host like a windows service which will keep the resources for the life of the services.
I was hoping I could write data portal host agnostic code and not have to reference System.Web from within my BusinessLogic layer in order to get to the HttpContext. Just thinking about that, could I alternatively use some Global.asax HttpApplication events to save/restore the LocalContext to and from the HttpApplication.Application state?
That way I could extend the life of the LocalContext beyond the stateless call to the life of the application (ie. App Pool)?
OK, scratch the above.
I now reference the System.Web assembly in my BusinessLogic layer and have made my calls to access the local context go through a central point. Here I can check if we have an HttpContext and then use the Application State (Context.Application) instead of the Context.Items which seems to only live for the life ot the request anyway (will need to verify that still).
Thanks again.
Interesting.
HttpContext.Current.Items only lives for the life of the request. Ie. LocalContext is emptied out between service calls
HttpContext.Current.Application lives for the life of the application pool *
* In the typical Silverlight scenario where the ASP.NET application hosts a WCF service the HttpContext.Current is always null, unless you set the following in the <system.serviceModel ... /> section of your web.config file.
<serviceHostingEnvironment aspNetCompatibilityEnabled="True"
/>
This may or may not be suitable for your project.
Interesting MSDN article noting the differences of runnig WCF and ASP.NET side by side, or alternatively setting aspNetCompatibilityEnabled to true to run them together.
Also explains what to use instead of HttpContext when running side by side.
Good read for those so inclined.
THANKS Jaans!! Great article with concise and thorough content.
Sean
Copyright (c) Marimer LLC