good responses, but I think there is a problem in the original question. "Typical use" of a technology is a poorly formed question. No one has a "typical" scenario, and you should review the requirements of your particular problem before deciding on an implementation or approach. Your requirements should inform your solution.
For instance, Singletons [ie the Singleton pattern] is just another tool in our box, and like any tool, there are cases where it works, and others it does not. Specifically, if you need to centralize business logic [more applicable in a standalone application than a remote WCF service], or share memory or a resource, a Singleton works well. Of course, if you are sharing business logic, state is maintained in the call stack, and multi threading is moot. If sharing memory between consumer calls, then multi threading is an issue. As regards WCF, there are two modes [actually three, but the third is a special case of the first] of multi-threading behaviour you can specify,
// we are specifying that this service implementation is single-threaded
// and WCF should permit *at most* one call at a time. Any requests made
// simultaneously/concurrently are queued.
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Single)]
public class SingleThreadedNonThreadSafeService : IService { ... }
and
// we are specifying that this service implementation is multi-threaded
// and [hopefully!] thread-safe. WCF should permit any number of threads,
// or any number of simultaneous concurrent calls.
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Multiple)]
public class MultiThreadedThreadSafeService : IService { ... }
The Xml comments for ConcurrencyMode basically say the same thing as above.
If you DO NOT need to share business logic or memory between consumers, then DO NOT use a Singleton, the "model" DOES NOT fit the problem. It s like forcing a glass slipper on a step-sister s foot! And no one should ever have to see that.
Conversely, if no state is shared between calls, host an instance per-callsession.
