I have a WCF service which is used synchronously, but its ConcurrencyMode is set to ConcurrencyMode.Multiple value, because the service is stateless actually. How much overhead does this mode impose? Does it make sense to change the mode to ConcurrencyMode.Single?
+2
A:
It doesn't really impose any overhead - other than the fact that the single service instance must handle concurrent access, it has to be 200% thread safe - and that's fairly tricky programming.
Switching to ConcurrencyMode.Single makes programming it simpler - no more worries about concurrency in the service class. But it serializes all requests - only one at a time can ever be handled and thus will become a performance bottleneck quickly.
You mention your service is stateless - so why not make it use the usually agreed upon best practice - not a singleton, but a regular "per-call" service class. In that mode, each request gets a fresh new instance of your service class, there's no fussing about multithreaded programming needed (all the multithreading is handled by the WCF runtime), you get concurrent handling of multiple requests - to me, that's only benefits and no down sides!
marc_s
2010-06-30 14:04:52
Thanks for the answer.Regarding "per-call" mode, I plan to add some thread-safe dependencies to the service later. So I don't think that it is the best option to use "per-call" mode.
bsnote
2010-06-30 14:18:05
@bsnote: why not?? If the service is indeed stateless, why don't you use the simplest possible model for that? Why do you make it unnecessarily hard and difficult on yourself?
marc_s
2010-06-30 14:29:16
The problem is that dependencies will be injected to the service each time it's created. Probably the creation time is insignificant but what are the pros of "per-call" mode in this case if there is no need to deal with concurrency issues?
bsnote
2010-06-30 20:03:51
Programming the per-call service is going to be **a lot** simpler than a multi-threaded singleton service; and if you have a singleton with ConcurrencyMode-Single, you're limiting yourself very heavily to serialized processing - one request after another - no concurrency whatsoever. This will severely limit the service's ability to handle calls.
marc_s
2010-06-30 20:23:22