3

I have a WCF service with ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Multiple). I want to use ThreadStatic variable to srore data.

I start worrying about is it possible two parallel requests for the same or different operationContracts get handled by the same thread serverside, because if this happens my ThreadStatic variable will get overriden.(I.e. something like the thread changing between HttpHandlers and HttpModules in ASP.NET)

I made a spike service with the same ServiceBehaviour and maxConcurrentCalls="2". After that a wcf client called the service with 50 parallel requests and my worry did not occur. However this is not a 100% proof.

Thank in advance!

Asen Arizanov
  • 930
  • 1
  • 9
  • 11

3 Answers3

4

Irrespective of the ConcurrencyMode, a ThreadStatic value will persist when your request terminates and the thread is returned to the thread pool. The same thread can be reused for a subsequent request, which will therefore be able to see your ThreadStatic value.

Obviously this won't be true for two concurrent requests, because by definition they will be executed on different threads.

From comments:

Also by definition MSDN says: 'The service instance is multi-threaded. No synchronization guarantees are made. Because other threads can change your service object at any time, you must handle synchronization and state consistency at all times.' So it is not so obvious:)

This means that a single instance of your service class can be accessed concurrently by multiple requests. So you would need to handle synchronization for any accesses to instance members of the service class.

However ThreadStatic members are by definition only used by one thread (and hence one request) at a time, so don't need synchronization.

Joe
  • 122,218
  • 32
  • 205
  • 338
  • Hi, thanks for your quick reply. I have a disposing wrapper around the ThreadStatic variable(e.g. I am using an ambient desing pattern), so I do no have problem during thread reusing. Also by definition MSDN says: 'The service instance is multi-threaded. No synchronization guarantees are made. Because other threads can change your service object at any time, you must handle synchronization and state consistency at all times.' So it is not so obvious:) – Asen Arizanov Sep 19 '12 at 09:16
1

The direct answer to your question is Joe's answer.

However you mention in the comments you are using an ambient design pattern. That pattern is already implemented in WCF as the OperationContext and is specifically designed to be extensible. I highly recommend using OperationContext over any custom thread storage.

See Where to store data for current WCF call? Is ThreadStatic safe?

Community
  • 1
  • 1
ErnieL
  • 5,773
  • 1
  • 23
  • 27
  • Thanks for bringing to my attention the Extensibility of WCF. However I will continue to use my approach, because I should be able to use it in ASP.NET context. – Asen Arizanov Sep 20 '12 at 07:51
0

I wanted to add to Joe's answer here because I would recommend that you use some sort of correlation for your requests if you're needing to store state. The threading model will become very convoluted and unreliable in production.

Further, now imagine you have two IIS servers hosting this service and a hardware or software load balancer forward facing so that you can consume it. To ensure that the correct state is gathered you'll need correlation because you never know which server the service will be started on. In the post below I mocked up a simplified version of how that might work. One thing to keep in mind is that the SessionState would need to be kept in a shared location to all instances of the service, an AppFabric Cache server for example.

Global Variable between two WCF Methods

Community
  • 1
  • 1
Mike Perrenoud
  • 66,820
  • 29
  • 157
  • 232