Can I use PerCall instancing and Reentrant concurrency in the same service?

I've been studying the instancing and concurrency modes in WCF and I'm trying to understand if there is any case where it makes sense to use PerCall instancing and Reentrant concurrency. In the following MSDN link it is stated that "in PerCall instancing, concurrency is not relevant".

The use of concurrency is related to the instancing mode. In PerCall instancing, concurrency is not relevant, because each message is processed by a new InstanceContext and, therefore, never more than one thread is active in the InstanceContext.

However, I think there might be a case where these two modes (PerCall and Reentrant) must be used in conjunction. Please correct me and/or give me any input on this. Consider the followin开发者_StackOverflowg scenario:

Service A uses a Duplex MEP. Service A exposes an operation contract which returns an object (i.e, it is NOT a one way operation). The service's callback contract also exposes an operation contract which returns an object (i.e, it is NOT a one way operation). The service endpoint uses a wsDualHttp Binding.

The operation contract implementation calls the client's callback before returning. In this scenario, if I set the ConcurrencyMode to Single, a Deadlock will occur, whether if I set the ConcurrencyMode to Reentrant everything works as expected.

So, why is Microsoft saying that concurrency is not relevant in a PerCall mode?

Concurrency is bound to how many threads are accessing an Instance of the service (InstanceContext).

In percall instancing, every call creates a new instance of the service and its related resources as in ASP.Net. When the call is over, this instance would not be valid. More over, this instance would not be accessible by any other thread, even from the same session.

So that's the reason for the statement, "in PerCall instancing, concurrency is not relevant".

Regarding your scenario, in Duplex MEP, let's say A is the client and B is the service.

When A calls B, an instance of Service is created. In duplex MEP the response has to happen through a different channel (callback channel), and the execution has to jump to a different instance (client instance which you set during the proxy creation) for execution. After completing this, it has to jump back to the original service instance and continue from where it left.

So in order for a duplex MEP to be successful, it needs to keep the original service's instance alive and re-enterable, when it jumps over to the callback channel for execution. With percall instancing, this is not be possible.

That's the reason duplex channel is looking for Reentrant/Multiple concurrency and PerSession InstanceContextMode

Also note that when you don't specify the instance context mode, the default it PerSession.

In my opinion, the MSDN article is simplifying things. Concurrency mode does play a part in PerCall instancing mode.

Check out this blog post: http://blogs.msdn.com/b/rickrain/archive/2009/06/17/wcf-instancing-concurrency-and-throttling-part-2.aspx.

In the blog, the author had to use ConcurrencyMode.Multiple with PerCall, because using the default 'Single' wouldn't work well when multiple threads make calls to the service using the same proxy object.

In ConcurrencyMode.Single, if the binding uses reliable session then all calls in a channel are queued even for PerCall.

Also, what if you have static variable in the service class? PerCall doesn't make it thread-safe, as implied by the statement 'In PerCall, concurrency is not relevant".