Should WCF service typically be singleton or not?

Question

I believe Jimmy Nillson said he generally made his webservices singletons. Is this the preferred method, and with WCF? Other than making the service methods static, is there something else to be done?

Answer 1

Typically NOT. Singletons are a mess, since to make them perform well, you'll need to make them multi-threaded, and that's just asking for trouble unless you really really really know what you're doing.

The best practice for WCF is to use per-call instantiation - each request gets its own copy of the service class, no multi-threading worries, good performance - store anything that needs to persist in a database - works like a charm.

The only real scenario where singleton might make sense is if you have to have all service request be using/handled by a physical resource that's available only in a single instance - if your singleton service serializes and thus protects a single resource, then it makes sense to use it.

Otherwise - spare yourself the trouble! :-)

Answer 2

Singleton WCF services should hardly ever be used- Singletons are the enemy of scalability! They only make sense in weird scenarios- logging to a single file, a single communications port or hardware device.

As Marc says the best choice for scalability with WCF is per call services (they offer the best trade off between performance and scalability). Per call services also work very well with load balancing.

Answer 3

Oi - 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 thread per call.
[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
// per call.
[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-call\session.