In Asp.Net apps, we are used to storing data in the current context. Objects that are specific to the currently executing Request, like a User object retrieved a database, or another object that you want to make globally available without requiring multiple database trips, can benefit from this.
But what about this situation in non-web applications? Or what about situations like an assembly that needs to have this contextual caching logic coded into it, but needs to be used from both web and non-web applications?
Below is an example of a static property that stores a User object, which is retrieved from a database, in the current HttpContext. If it is already available in Context, it simply returns it.
What will happen if this property is accessed from a non-Asp.Net application, such as a windows service? HttpContext.Current will return null, and we will get an exception.
We could simply store a static field in this class and access that if HttpContext.Current is null. But if that application has more than one thread, such as a Windows Service that is hosting a WCF Service, the static field will be shared across all threads.
Right?
Right - Unless we add the [System.Threading.ThreadStaticAttribute] to it!
Below is the updated property that will work in both kinds of applications:
There you go - a property access to contextual variable that caches for the length of the current thread, and isolated to the current thread.
Awesome!