tags:

views:

70

answers:

1

I need some HttpApplication local storage. I thought the ApplicationState was the place for this, but apparently this may be shared across HttpApplication instances in an Appdomain.

   public class MyHttpModule : IHttpModule
    {
        private object initializingLock = new object();

        private static HttpApplication last;

        public void Init(HttpApplication context)
        {
            lock (initializingLock)
            {
                // always is false, as expected
               if (last == context) 
               { 
               }

               // is true for 2nd HttpApplication in AppDomain!
               if (last != null && last.Application == context.Application)                    
               {                   
               }

               last = context;
            }
        }
     }

What's the best blace to use to store some data that's per HttpApplication that other stuff can access?

A: 

If you are coding for particular (or controlled set of) web application then you can add whatever state that you need in your HttpApplication in global.asax such as

public class Global : System.Web.HttpApplication
 {
    string MyProperty { get; set;}
    ....

Then in your module, you cast the HttpApplication to Global and access the state. For example,

var myApp = context as Global;
if (null != myApp) 
{
    var value = myApp.MyProperty;
    ...
}
VinayC
-1 for no locking
John Saunders
@John Saunders, I am simply illustrating how to have state per HttpApplication object. Whether locking will be needed or not would depend upon overall implementation and usage pattern. Its my understanding that *one HttpApplication instance* will serve *one request at a time* so its quite possible to use instance variables of HttpApplication object w/o explicit locking if its usage is limited within a scope of request.
VinayC
This works, but I was hoping for something that will work in a dll, where I do not control the HttpApplication itself (and thus don't control the global.asax, only my HttpModule)...
JeffN825
@John Saunders: SO isn't a place where people ask other people to write code FOR them, right? I wouldn't expect any code supplied in a answer to any question on SO to be production ready, or anything more than a hint at how to go about implementing something.....
JeffN825
BTW, right now my solution, though undesirable, is to do HttpContext.Current.ApplicationInstance.Modules.Keys.Select(k=>HttpContext.Current.ApplicationInstance.Modules[k]).OfType<MyModule>().First().MyProperty
JeffN825
@jeffn825, why not use a dictionary (static field in module) to associate an application instance with the extra state information that you want to track? Yes, you need to use it in thread-safe way - I will probably use something from System.Collections.Concurrent namespace to make things simpler.
VinayC
@jeff: many people simply copy code examples they see. That's how they are taught to do their jobs.
John Saunders
@John, I agree. But I believe that MyProperty (being string) from my example does not need locking ;-).
VinayC
@Vinay: Remove the setter and it won't need locking. Otherwise, it does. You have no reason to believe that setting that property is an atomic operation.
John Saunders
@John: That's very unfortunate, though I'll grant you, perhaps true. Still, I don't think Vinay's answer should be penalized for coding without locking.
JeffN825
@Vinay: I don't want to stop the HttpApplication from getting GC'd by hanging on to it in a dictionary (that would be bad).
JeffN825
@jeff: he need only correct the lack of locking (perhaps by removing the setter), and I'll "correct" the -1.
John Saunders
@John, I still believe that HttpApplication instance variables won't need locking in most (common) usage scenarios while static variables will need locking most of the time. E.g. most of modules/handlers are likely to work with current application instance. Its unlikely that module will refer application object for other request (by caching its ref). Typically, no one expects to lock session variables although its possible to inject ref of mutable object on multiple sessions causing potential issues - but these will be corner scenarios.
VinayC
@Jeff, good point, missed on to it. Perhaps you can use WeakReference to HttpApplication.
VinayC