0

On the MSDN page for the Membership.ApplicationName property (which applies to an asp.net membership provider), it warns that although one can change Membership.ApplicationName in code, 'The ApplicationName property is not thread safe for multiple writes, and changing the ApplicationName property value can result in unexpected behavior for multiple users of an application.' They therefore recommend avoiding using it for a 'web application'.

This is because the default SqlMembershipProvider is written as a singleton. But here's my question: is it OK if all the threads in my application process are going to set Membership.ApplicationName to the same thing?

I'm thinking of having multiple applications on my IIS box, each with their own separate application pool. I want to point them to the same location, but based on the hostname, set the application provider to different things. Wouldn't this actually be OK? It might not be a thread-safe operation, but doesn't each application pool have its own process and therefore its own instance of SqlMembershipProvider? So, every thread that tried to set Membership.ApplicationName for a given SqlMembershipProvider instance would be trying to set it to the same thing (the provider that is appropriate for that hostname). Or am I missing something?

I guess the main question is, do ALL asp.net applications share one SqlMembershipProvider, or is a separate one created for each application pool process?

Jez
  • 27,951
  • 32
  • 136
  • 233

1 Answers1

1

Each application pool would have it's own MemberShip.ApplicationName so you'd be safe.

With regard to the SQL Membership Provider the same would apply. Because each site is in its own application pool they are distinct and separate.

In fact even in the same application pool but where you had separate ASP.NET applications (i.e. you clicked on the Create Application on a folder for each of them) there would be distinct objects. This is because the unit of application isolation in .NET is the Application Domain which you could describe as a soft process boundary within a Windows process.

To answer the question in your comment, this page on the MS ASP.NET QuickStart tutorials probably explains this and is straight from the horses mouth:

Understanding Applications and State

To quote:

Each ASP.NET Framework application on a Web server is executed within a unique .NET Framework application domain, which guarantees class isolation (no versioning or naming conflicts), security sandboxing (preventing access to certain machine or network resources), and static variable isolation.

Kev
  • 118,037
  • 53
  • 300
  • 385
  • Thanks, Kev... I was really wanting that answer. :-) Not trying to call your expertise into question but could you point me to any web pages (preferably written by MS) that state this point clearly? It'd be nice to have it from a really authoritative source. I'd assumed this to be the case, but as I mentioned, I don't think the MSDN page on `Membership.ApplicationName` describes the situation very clearly. – Jez Dec 05 '10 at 23:47
  • Kev: which kind of begs the question, why the big scary 'Caution' on the Membership.ApplicationName MSDN page? It should at least mention that you can actually separate these instances of SqlMembershipProvider quite easily. – Jez Dec 06 '10 at 00:44
  • @Jez - Ok...ApplicationName is a static value which means that it's global to the whole application (running in its own application domain). So if you have two requests. Request 1 begins by setting ApplicationName, does some work and perhaps there's a longish running operation in the code (you call a webservice) and then calls a method on some class that reads ApplicationName. Request 2 comes along and sets ApplicationName to a different value while request 1 is waiting on the results from the long running operation..boom!. That's why you need to exercise caution. However.... – Kev Dec 06 '10 at 01:17
  • @Jez - ...this all happens inside one single ASP.NET application which is isolated in an App Domain. Setting this static value will not affect ASP.NET applications hosted in other applications (even in the same worker process). – Kev Dec 06 '10 at 01:18
  • @Jez - It's basic .NET 101. Static values are only global to an application domain. An application pool can run many ASP.NET applications (each one runs in its own application domain). Trust me, I see this in action every day (I'm an ASP.NET hosting engineer for a web hoster) because we run multiple sites per application pool. Our customers use the membership providers without stomping over each other's global statics because of app domain isolation. – Kev Dec 06 '10 at 01:25
  • I want a member on one site to be able to update a member on another. How should this be done? Using the SQL SPs? My first shot at the problem was to set the Membership.ApplicationName, update, then set it back - but it needs to be threadsafe, because both Applications are valid and have users which I need to check, so I guess I need a different approach? – Ian Grainger Dec 06 '10 at 16:12
  • @Ian - you should ask this as a new question and perhaps reference this one as related. Tacking on questions in comments or answers is verbotten in SO. Also asking as a new question you'll get far better visibility and fresh eyes. – Kev Dec 06 '10 at 16:17
  • OK, thanks Kev. Asked: http://stackoverflow.com/questions/4368792/create-user-in-another-membership-applicationname – Ian Grainger Dec 06 '10 at 16:45