Jeff and .NET

You can always put an appsetting in and then check the value of the setting when you go to create the object in Application_Start.

Just use the standard singleton pattern.  I've had to fix bugs where someone used a static variable inappropriately, so I know it works. :-)

Now if you are trying to do a singleton per request, that's different.

I guess maybe why do you think this is not working?

I was under the assumption that creating a static var in global scope would work.  Maybe I'm mistaken...

Darn. I thought you were implying about a Singleton that lives across a Web Farm. Now that would be cool.

Here are a couple of implementations that I have found to work:

www.yoda.arachsys.com/.../singleton.html

Implementing a singleton inside an ASP.NET application is nothing different from a normal application. However if you are like Dave T. says are implying to make it also working on a webfarm, then I indeed think that is a very nice challenge :)

Follow the Yoda link, fully nested.

For the webfarm you would probably be better off to use a service that lives on one machine ;)

Jeff, the web garden will kill you every time, not to mention the idle timeout. See the application pool properties (msdn2.microsoft.com/.../Aa720391(VS.71).aspx) and you'll see that the very things that make IIS 6 so scalable, also make it very tough to maintain a true singleton. You have two choices. Turn off the scalability features by going down to one worker process and a number of other items, or use an independent application such as a windows service and then remote to your singletons. It's not pretty, but it's the price you pay for scalability.

Jeff, what are you actually trying to do? If you need a singleton that is local to the AppDomain a static variable anywhere should work. I tend to use a global App object from which any statics hang off of. (ie.  App.SingleInstance, App.Configuration etc.). You can also define these on HttpApplication as long as you make sure they the properties/fields are static.

Hmm... Some people made comments here that are just flat wrong.

IIS can & will create multiple worker processes. If you are running in a web garden mode IIS will create a worker process for each core in the system. IIS will also recycle processes on a single core machine; i.e. spin up a new process and process new requests on it while shutting down an old process that is done processing requests.

The ASP.NET worker process is a process just like any other process. So if you wrote a windows form application and ran two copies of it. Each AppDomain in that process, each static, everything is completely isolated from the other instance of your application. ASP.NET worker processes are no difference.

This means that if you want to share absolute consistent state across an ASP.NET application you *have* to implement that state server as a windows services that loads prior to the WWW service loading. And you *have* to talk to that state server through a mechanism like System.Remoting.Channels.Ipc (inter process communication remoting stack)

Most of us are lazy and just use a SQL Server database. If you need to use rich objects try MSMQ or the Session State service.

hth,

Paul

It's even worse than that - ASP.NET can create multiple Application Pools within one worker process - and yes, they'll have separate set of static fields each. I stumbled across this problem and found no workaround which would not cripple efficiency and robustness. The "solution" was to use an external cache process which stored some objects. It obviously worked only with serializable objects (pieces of data, actually); if you need a fully functional, mutable object than it's even more of a challenge.