How do singleton patterns work in a web context?

Steve, I'll try to answer each of your questions:

1) For web development it is very common to have objects scoped to the web request (sometimes this is also referred to as "per request context" or "per http context"), but we typically don't refer to these as singletons for that exact reason. Most IOC containers in fact have a "per web request" scope built into them out of the box as well as a "singleton".

2) It is common to sometimes have true singletons for a web application as well (accessed by all requests). As mentioned above this isn't completely true because it's going to be scoped to the app pool and will be blown away when/if the app pool is restarted. But this is a singleton for the purposes of the web application. As Jigar mentioned, sometimes "cross-cutting concerns" such as logging etc...are set up this way. These are typically not initialized in each web request but instead in the global.asax or by relying on an IOC container to do this for you. You just have to be sure when performing object creation to use one of the standard locking patterns to prevent two threads/clients/etc... from simultaneously creating the object. Here's a link from Microsoft but there are other implementations out there as well: http://msdn.microsoft.com/en-us/library/ff650316.aspx If you are using one of the popular IOC containers it will take care of this for you (Structuremap, Windsor, Autofac, Unity, Ninject...and many others).

You'd need to ask your coworkers which approach they are referring to because both are valid in certain situations and very common.

It all depends on your singleton implementation. Here I assume that you create singletons as static fields initialized in static constructors.

Theoretically depending on its settings IIS may create several processes for your application, and each process can create several threads for processing requests. Each process would have its own singletons, that can be shared amount several threads (and several requests). But in the same time there can be several instances of "singletons" (one for each process) on one server (but, if I understand correctly, several processes can be prohibited in IIS settings).

If you use static constructors, then singletons would be created on the first access to your class in a thread-safe way. See Is the C# static constructor thread safe?

But although singleton creation is thread-safe, you still must implement insides of your singleton class in a thread-safe manner.

Singletons would live while your application process lives and isn't restarted. Lifetime of application process is managed by IIS, so it can be a long time or a very short time.

Singleton's are maintained by IIS, so the singleton only lasts as long as the IIS application pool. Once this is recycled or IIS is reset then the singleton disappears. You'll need to lock the singleton for multiple access. Like you would in any other client server app.

Generally I'd try an avoid it as it's kind of against the idea of a web site being essentially a stateless client server app. Why not just use Session to store any shared data?