WCF Instancing and Concurrency

InstanceContextMode, set via [ServiceBehavior(InstanceContextMode = InstanceContextMode.X)], controls the lifetime relationship between service instances and client calls. PerCall (the default for wsHttpBinding without sessions) creates a brand-new service instance for every single operation call and disposes it immediately after, which means the service class can never hold state between calls — great for stateless, horizontally scalable services. PerSession creates one service instance per client session and keeps it alive for the duration of that session, letting the service hold conversational state (like a shopping cart accumulated across several calls) in instance fields. Single creates exactly one service instance for the entire application's lifetime, shared by every client and every call, which is useful for scenarios needing a shared in-memory cache or counter, but which makes that single instance a potential bottleneck and a thread-safety hazard if not paired with the right ConcurrencyMode.

ConcurrencyMode, also set on [ServiceBehavior], governs how many threads WCF allows to execute inside a given service instance context simultaneously. Single, the default, serializes all calls into an instance context with a lock — only one thread executes inside that instance at a time, which makes instance fields inherently thread-safe without any manual locking, at the cost of throughput if that instance is called frequently. Multiple allows several threads to execute concurrently inside the same instance, which is necessary for a Single-instanced service to actually scale under load, but it means every mutable field the service touches must be protected with explicit locks, concurrent collections, or Interlocked operations, because the runtime provides zero automatic thread safety. Reentrant, a middle ground, still serializes calls like Single but releases the lock when the operation makes an outbound call (to another service or via a callback) and reacquires it on return, which prevents deadlocks in callback-heavy duplex scenarios but reintroduces the possibility of the instance's state being mutated by another thread while the outbound call is in flight.

The instancing and concurrency modes are configured together, and certain combinations are especially common in practice. InstanceContextMode.Single with ConcurrencyMode.Single is the safest way to build a shared, stateful, in-memory cache service, since every call is fully serialized — but it also means the service's entire throughput is bounded by however long one call takes, so long-running operations on this combination will bottleneck every other client. InstanceContextMode.Single with ConcurrencyMode.Multiple unlocks real concurrency for a shared instance but shifts the thread-safety burden entirely onto the developer, who must treat every field like it's being hit by concurrent requests from unrelated clients simultaneously — a mistake here (an unprotected Dictionary.Add call, for instance) produces intermittent, hard-to-reproduce corruption under load rather than a clean crash.

The practical throughput ceiling of a WCF service is a direct function of these two settings combined with the service throttling behavior covered elsewhere: PerCall with Multiple concurrency (its effective default combination) scales best for stateless workloads since WCF can freely spin up many concurrent instances handled by the thread pool, while Single with Single concurrency caps the service at strictly one operation executing at any given moment regardless of how many CPU cores or how large the thread pool is. A common production mistake is choosing InstanceContextMode.Single for convenience — because it feels like a familiar singleton pattern from other application designs — without realizing that pairing it with the default ConcurrencyMode.Single silently turns a supposedly scalable web service into a de facto single-threaded bottleneck under real concurrent load.