Section 9.5. Concurrency Management

9.5. Concurrency Management

As with a connected service, the ConcurrencyMode property governs concurrent playback of queued messages. With a per-call service, all queued messages are played at once to different instances as fast as they come off the queue, up to the limit of the configured throttle. There is no need to configure for reentrancy to support callbacks, because the operation contexts can never have a callback reference. There is also no need to configure for multiple concurrent access because no two messages will ever share an instance. In short, with a queued per-call service, the concurrency mode is ignored.

When it comes to a sessionful queued service, you are required to configure the service with ConcurrencyMode.Single. The reason is that it is the only concurrency mode that allows you to turn off auto-complete, which is essential to maintain the session semantic. The calls in the message are always played one at a time to the service instance.

A queued singleton is really the only instancing mode that has any leeway with its concurrency mode. If the singleton is configured with ConcurrencyMode.Single, WCF will retrieve the messages all at once from the queue (up to the thread pool and throttling limits) and then queue up the calls in the internal queue the instance lock maintains. Calls will be dispatched to the singleton one at a time. If the singleton is configured with ConcurrencyMode.Multiple, WCF will retrieve the messages all at once from the queue (up to the thread pool and throttling limits) and play them concurrently to the singleton. Obviously, the singleton must provide for synchronized access to its state. If the singleton is also transactional, it is prone to transactional deadlock over prolonged isolation maintained throughout each transaction. Not only that, but a transactional singleton with ConcurrencyMode.Multiple must have ReleaseServiceInstanceOnTransactionComplete set to false and at least one operation must have transactionScopeRequired set to TRue:

 [ServiceBehavior(InstanceContextMode = InstanceContextMode.Single,                  ConcurrencyMode = ConcurrencyMode.Multiple,                  ReleaseServiceInstanceOnTransactionComplete = false)] class MySingleton : IMyContract {    [OperationBehavior(TransactionScopeRequired = true)]    public void MyMethod( )    {...} } 

9.5.1. Throttling

The throttling of a queued service is your way of controlling the stress of the service and avoiding turning load into stress. The important value to throttle is the number of concurrent playbacks. This is an effective way of throttling the number of played messages because if the number of concurrent calls is exceeded (overall stress) then the maxed-out messages will stay in the queue. For example, if a service has 50 messages in the queue, it may not want to have 50 concurrent instances and worker threads. With a per-call service, the throttle controls the overall number of allowed concurrent instances (and their implied resource consumption). With a per-session service, the throttle controls the number of allowed sessions. In the case of a queued singleton, you can combine a throttled value with ConcurrencyMode.Multiple to control just how many concurrent players are allowed (stress) and how many messages to keep in the queue (buffered load).