locked
Is ThreadStatic Attribute Dangerous in WCF? RRS feed

  • Question

  • I'm using the [ThreadStatic] attribute to provide some global context in my WCF service, so I don't have to keep passing information around, like the user ID for the service call.  But is this dangerous because my WCF service call might be switched out to another thread?

    So far my app is working fine, but I need to be sure of this.  If the thread gets switched out, my context will be unreliable and the app will most likely break (and this will not be easy to debug).

    To explain it another way, whenever a service call comes in I set this ThreadStatic property, and various objects that get called from the service method (e.g. business objects, data managers, etc.) query this property (for example to get the current user ID).  As long as the thread remains the same until the end of the service method, I am good.  I don't care if next time the service method is called that it's on a different thread.  But I need to absolutely sure that the thread won't get switched out under me *during* a service method's execution.

    If I cannot be sure of this then I can no longer use my ThreadStatic attribute approach, and I guess I'll need to pass context around or use WCF's OperationContext.  The problem with using OperationContext is that these business objects and data managers are not only called from a WCF service method.

    Thanks for any help.

    -Larry
    Monday, March 1, 2010 8:54 PM

Answers

  • Hi Larry,

    As for ThreadStaticAttribute decorated property, they will be automatically isolated between thread boundary. For your scenario, you want to use such properties in WCF service operation code, here are my comments:

    ** WCF (like ASP.NET) will use CLR threadpool thread to handle each service operation requests from client, so in most cases the operation call's thread context will be the same. However, there will still have some exceptions such as the custom usernamePasswordValidator is called in a different background thread(in such cases, it is not safe to assume that the ThreadStaticAttribute decorated static properties are the same as in service operation code).


    ** If possible, I suggest you use OperationContext assocated properties to store your context data or you can always perform a check like:

    if(OperationContext.Current != null)
    {
     //access ThreadstaticAttirbute properties here..

    }

    This can help make sure that you're within the WCF operation's context thread.






    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Wednesday, March 3, 2010 6:45 AM

All replies

  • I was believing so far that it will be executed on same threads but below link says something else-

    http://blogs.microsoft.co.il/blogs/applisec/archive/2009/11/23/wcf-thread-affinity-and-synchronization.aspx

    I'm having the feeling the that it should work if thread is not waiting for long duration (how long? I don't know). Link has mentioned the DB operation as well. I think somebody should help to figure out cases under which thread switching can happen.

    BTW, I was also having the requirment to access login user id in business operation and I used to set it in business instances when service object used to access them.

    Gurmit

    Wednesday, March 3, 2010 5:55 AM
  • Hi Larry,

    As for ThreadStaticAttribute decorated property, they will be automatically isolated between thread boundary. For your scenario, you want to use such properties in WCF service operation code, here are my comments:

    ** WCF (like ASP.NET) will use CLR threadpool thread to handle each service operation requests from client, so in most cases the operation call's thread context will be the same. However, there will still have some exceptions such as the custom usernamePasswordValidator is called in a different background thread(in such cases, it is not safe to assume that the ThreadStaticAttribute decorated static properties are the same as in service operation code).


    ** If possible, I suggest you use OperationContext assocated properties to store your context data or you can always perform a check like:

    if(OperationContext.Current != null)
    {
     //access ThreadstaticAttirbute properties here..

    }

    This can help make sure that you're within the WCF operation's context thread.






    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Wednesday, March 3, 2010 6:45 AM

  • Hello Steven,

    Given link does not consider the case of "UserNamePasswordValidator". As per link- thread might get switched even in service operation code. Could you please throw the light, with an example, under what circumtances this can happen? Attached link mention about DB but it does not give any idea about example.

    Regards,
    Gurmit
    Wednesday, March 3, 2010 8:07 AM
  • OK, I think the suggestion of using operation context first and falling back to thread storage if it's null is a good approach.

    Thanks for the responses.
    Wednesday, March 3, 2010 2:04 PM