13

Haven't come across this one with quite a bit of Googling.

I know I can set the instance by decorating the class name thus:

[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall, 
                 ConcurrencyMode = ConcurrencyMode.Multiple)]

but can I specify this in the web.config file?

I know I can specify throttling (max concurrent users etc) in the web.config / app.config and that the numbers here have a context depending on the instance mode - but how to specify the mode (in most likely the behaviours section of the app.config / web.config)?

Originally we were going for Windows services. Now we are using WAS. Does WAS make any difference - eg. each 'per call' request will still get's it own 'server' as a pipeline operation?

Thanks

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
wcfhopeful
  • 131
  • 1
  • 1
  • 3

3 Answers3

10

You can't change InstanceContextMode and ConcurrencyMode in web.config with out of the box functionality but you can write your custom extension (behavior or custom ServiceHost + ServiceHostFactory + config section) to do that. Here is the example how to change InstanceContextMode without defining it in attribute on the service class.

Processing in WAS is the same - each service type still have its own service host and each request is processed in its own thread.

Community
  • 1
  • 1
Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670
1

As per the previous answers, you cannot do this without a bit of work. I had to do this for a customer recently and I have documented it here. I have also provided a validator to not allow the service to start if it is not configured how you would like it. The details are here changing-wcf-concurrency-programatically.

SoftwareSimian
  • 104
  • 2
1

You can not configure InstanceContextMode and ConcurrencyMode in config files, build in limitation in the WCF, i am sure MS has their reasons.

About hosting in WAS, if you have a web server with IIS 7/7.5 it is recommended to host your service with WAS because you can manage your services with the IIS management and get a lot of built in capabilities from it.

Gilad Levy
  • 13
  • 4
  • I agree, the first reason I can see is the architecture of the service itself: to be used as a singleton the service must have been designed to keep the state and manage concurrency, changing this fundamental behavior from outside (i.e. the config file) might have unpredictable effects on the application. – Leonardo Spina Nov 28 '18 at 21:30