Is there a way to configure a WCF Service to create a new Thread to handle any new incoming request?
A:
No, because you would never want to do this. What are you really trying to achieve?
EDIT
Based on more info coming in, here's what I think.
If you just want "sticky state" per request, you should use the state on the Instance and use InstanceContextMode.PerCall, as per marc_s's response.
If you need some state to be in thread-local storage for your call, you can consider using ICallContextInitializer as a way to marshal the state over to the thread that WCF chooses to invoke your method on (and clean the thread state when the call finishes).
But you should not care about "which thread". WCF will handle that with a thread pool on your behalf.
Brian
2009-09-16 05:59:48
Could you explain a little more?
Chuck Conway
2009-09-16 06:02:11
The idea is to share db sessions, credentials,etc within a request by storing these in ThreadContext. This will help us in doing rollbacks, etc.
Nazgul
2009-09-16 06:10:34
of course you can - it's actually even the recommended best practice! The ServiceHost has a pool of worker threads for this exact purpose
marc_s
2009-09-16 06:30:28
marc_s can you please explain how
Nazgul
2009-09-16 06:45:24
I dont care which thread as long as new one is created for every request. Right now it is handling every request with the same thread so the db sessions are being shared, which is leading to weird problems.
Nazgul
2009-09-16 06:56:41
You don't actually want a new thread for every request. You just want the db stuff to run right; what you really want is for each request to set up whatever thread-local-storage (TLS) to be independent of other requests (e.g. avoid the shared db sessions). I don't know particularly what thread-local state is at play here, but learn that, and address that (possibly even the WCF transaction features make this as simple as an attribute or a configuration switch - unfortunately I dunno the details). But you do not want to solve this at 'thread' level, you want to solve it at TLS level.
Brian
2009-09-16 07:07:15
+3
A:
Yes you can do that - it's called "per-call" handling of requests. The ServiceHost will create a new instance of your service class for each request coming in to handle that one request.
To do this, you need to set your Service class (the one implementing the service interface) to be "PerCall" - you do this by applying an attribute on your service class:
[ServiceBehavior(InstanceContextMode=InstanceContextMode.PerCall)]
public class YourService : IYourService
{
...
}
Marc
marc_s
2009-09-16 06:30:00
This will create a new Service instance per call, but does not spawn a new thread per call.
Nazgul
2009-09-16 06:33:28
but it will assign the new service instance to a worker thread to handle the request......
marc_s
2009-09-16 07:19:54
I don't think you can do more than this. I don't know of any setting in WCF to specifically create a brand new thread for each request. And why would you really want to?? Creating a full-blown thread is quite an expensive operation - why not use the built-in pool of worker threads that are already available?
marc_s
2009-09-16 07:22:54
A:
Depends on what exactly you want, but the following service behaviour will solve it:
ServiceBehavior:
ConcurrencyMode=ConcurrencyMode.Multiple
InstanceContextMode=InstanceContextMode.Single
Your class will be a singleton, but all calls made to the methods will run in a separate thread. If you need any synchronization though you have to do it manually.
Also don't forget to look into throttling to be aware of potential performance issues.
dr. evil
2009-10-24 14:30:21