Instances and Concurrent Access





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.

Per-Call Services

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.

For a per-session service configured with ConcurrencyMode.Mutiple to experience concurrent calls, the client must use multiple worker threads to access the same proxy instance. However, if the client threads rely on the auto-open feature of the proxy (that is, just invoking a method and having that call open the proxy if the proxy is not opened yet) and call the proxy concurrently, then the calls will actually be serialized until the proxy is opened, and be concurrent after that. If you want to dispatch concurrent calls regardless of the state of the proxy, the client needs to explicitly open the proxy (by calling the Open( ) method) before issuing any calls on the worker threads.




 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows