Concurrency and instance context patterns: Concurrent performance of WCF services in different instance context modes

Because WCF concurrency is for a instancecontext that encapsulates a service instance, different concurrency behaviors are displayed in different instance context modes. Next, we dissect WCF concurrency from the perspective of specific instance context patterns, and if you don't know the WCF instance context pattern and the instance context provider mechanism, see Chapter 9th of WCF Profiling (Volume 1).

In "Practice over theory", I write a simple WCF application, through which we can clearly monitor the implementation of client and service operations. In this way, we can and intuitively see the service side for concurrent service invocation requests, in the end is the use of parallel or serial execution. Next, we will make full use of this monitoring program, with examples demonstrating the combination of principle analysis of different instances of the context of the implementation of the mechanism of the depth analysis.

A monotone (Percall) instance context pattern

Because WCF concurrency is for a instancecontext that encapsulates a service instance, the WCF server runtime always creates a new instancecontext to handle each request for a monotonous instance context pattern. Whether the request is from the same client or not. So in the case of monotone instance context mode, there is no occurrence of a concurrent call to a instancecontext.

We can verify this by our monitoring program. To do this, we need to set the instance context pattern to Instancecontextmode.percall by ServiceBehaviorAttribute, and the relevant code looks like this.

1:　[ServiceBehavior(UseSynchronizationContext　=　false,InstanceContextMode　=　InstanceContextMode.PerCall)]
2:　public　class　CalculatorService　:　ICalculator
3:　{
4:　　　//省略成员
5:　}

The following is the code that clients make concurrent service calls:

1:for (int i = 1; I <= 5; i++)
2: {
3:threadpool.queueuserworkitem (state =>
4: {
5: int clientId = interlocked.increment (ref clientidindex);
6:icalculator proxy = _channelfactory.createchannel ();
7:using (proxy as IDisposable)
8: {
9:eventmonitor.send (clientId, eventtype.startcall);
　　　　　　　10:using (OperationContextScope contextscope = new OperationContextScope (proxy as IContextChannel))
11: {
12:messageheader<int> messageheader = new messageheader<int> (clientId);
13:operationcontext.current.outgoingmessageheaders.add (Messageheader.getuntypedheader (EventMonitor.CientId Headerlocalname, Eventmonitor.cientidheadernamespace));
14:proxy. ADD (1, 2);
15:}
16:eventmonitor.send (ClientId, Eventtype.endcall);
17:}
:}, NULL);
:}

If we run our monitoring program on this basis, we will get the output as shown in Figure 1, from which we can see that we still adopt the default concurrency mode (concurrencymode.single), and call requests from 5 different clients (service agents) can be processed in a timely manner.

Fig. 1 Concurrent Event monitoring output (different clients) in monotone instance context mode