May 24, 2011, 7:28 p.m.
posted by orel
Instances and Concurrent Access
Using the same proxy, a single client can issue multiple concurrent calls to the service. The client could use multiple threads to invoke calls on the service, or the client could issue one-way calls in rapid succession. In both of these cases, concurrent processing of the calls from the same client is a product of the service's configured instancing mode, the service's concurrency mode, and the configured delivery; that is, the binding type and the session mode.
In the case of a per-call service, if there is no transport-level session; that is, if the call is made over the BasicHttpBinding, or over any of the WS bindings when the contract is configured for SessionMode.NotAllowed, or for SessionMode.Allowed yet without security and reliable messaging, concurrent processing of calls is allowed. Calls are dispatched as they arrive, each to a new instance, and execute concurrently. This is the case regardless of the service concurrency mode. I consider this to be the correct behavior.
If the per-call service has a transport-level sessionthat is, the binding is either TCP or IPC, or a WS binding when the contract has its SessionMode set to either SessionMode.Allowed with security or reliable messaging, or SessionMode.Required concurrent processing of calls is a product of the service concurrency mode. If the service is configured with ConcurrencyMode.Single, then concurrent processing of the pending calls is not allowed. While this is a direct result of the channel architecture, I consider this to be a flawed design, since the lock should be associated with an instance, not a type. If the service is configured with ConcurrencyMode.Multiple, concurrent processing is allowed. Calls are dispatched as they arrive, each to a new instance, and execute concurrently. When the service is configured with ConcurrencyMode.Reentrant, if the service does not call out, it behaves similarly to ConcurrencyMode.Single. If the service does call out, the next call is allowed in, and the returning call has to negotiate the lock like all other pending calls.
Sessionful and Singleton Services
In the case of a sessionful or a singleton service, the configured concurrency mode alone governs the concurrent execution of pending calls. If the service is configured with ConcurrencyMode.Single, then calls will be placed to the service instance one at a time. Pending calls will be placed in a queue. You should avoid lengthy processing of calls because it may risk call timeouts.
If the service instance is configured with ConcurrencyMode.Mutiple then concurrent processing of calls is allowed. Calls will be executed by the service instance as fast as they come off the channel (up to the throttle limit). As is always the case with a stateful unsynchronized service instance, you must of course synchronize access to the service instance or risk state corruption.
If the service instance is configured with ConcurrencyMode.Reentrant, it behaves just as with the ConcurrencyMode.Single. However, if the service does call out, the next call (be it one-way or not) is allowed to execute. You must follow the guidelines discussed previously regarding programming in a reentrant environment.