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

Question

I am studying instancing and concurrency modes in WCF, and I'm trying to figure out if there is any case where it makes sense to use PerCall instancing and Reentrant concurrency. The following MSDN link states that "PerCall instancing concurrency doesn't matter."

Using concurrency is associated with instancing mode. In increments of PerCall, concurrency does not matter because each message is processed by a new instance of InstanceContext, and therefore no more than one thread is active in the instance text.

However, I think there may be a case where these two modes (PerCall and Reentrant) should be used together. Please correct me and / or give me any data on this. Consider the following scenario:

Service A uses duplex MEP. Service A provides a work contract that returns an object (i.e. This is NOT a one-way operation). The service callback contract also provides a work contract that returns an object (i.e. This is NOT a one-way operation). The service endpoint uses the wsDualHttp binding.

Executing an operation contract causes a client callback before returning. In this case , if I set ConcurrencyMode to Single, a deadlock occurs , if I set ConcurrencyMode to Reentrant, everything will work as expected .

So why does Microsoft say that concurrency is not PerCall mode?

Answer 1

Concurrency is tied to how many threads access the service instance (InstanceContext).

In percall instancing, each call creates a new instance of the service and its associated resources, as in ASP.Net. When the call is completed, this instance is invalid. Moreover, this instance will not be available with any other thread, even from the same session.

So, the reason for the statement is "in PerCall instancing, concurrency doesn't matter."

For your scenario , in Duplex MEP, let's say that A is a client and B is a service.

When A calls B, an instance of the service is created. In a duplex MEP, the response must be through another channel (callback channel), and execution must go to another instance (the client instance that you installed during the creation of the proxy) to execute. Upon completion of this action, he must return to the original instance of the service and continue from where he left.

So, in order for the duplex MEP to be successful, it must keep the original service instance alive and re-injectable when it moves to the callback channel to execute. With percall increments this is not possible.

In this case, the duplex channel searches for Reentrant / Multiple concurrency and PerSession InstanceContextMode

Also note that when you do not specify an instance context mode, the default is PerSession.

Answer 2

In my opinion, the MSDN article makes it easy. Concurrency mode plays a role in PerCall instance mode.

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

On the blog, the author had to use ConcurrencyMode.Multiple with PerCall, because using the default "Single" would not work well if several threads made calls using the same proxy object.

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

Also, what if you have a static variable in a service class? PerCall does not make it thread safe, as implied by the expression "In PerCall, Concurrency does not matter."