none
Best practice for Service Operations with Task RRS feed

  • Question

  • From .net 4.5 is it now recommended to expose all WCF service operations with Task return types? So that for example, even if the service operation is only performing a few light computations in memory, scalability is improved by immediately returning a Task.Run() delegate?

    public Task<string> HelloWorld()
    {
    return Task.Run(() => 
       {
         // Do stuff here
    
         return "Hello World";
       });
    }

    I have read many of the informative blogs from messrs. Toub and Cleary. Much of what I have seen relates to Asp.net efficiency and deadlocking issues, and UI responsiveness.

    I realize that wrapping synchronous code with Task.Run() carries the overhead of creating an additional thread and seems to run counter to my reading of the expert advice, but surely the WCF runtime benefits from the immediate return of a Task object?


    Dick Page

    Tuesday, October 21, 2014 2:04 PM

All replies

  • Where did you come up with this stuff? Just becuase someone printed it, it doesn't make it a ends all stops all solution.
    Tuesday, October 21, 2014 2:25 PM
  • >>From .net 4.5 is it now recommended to expose all WCF service operations with Task return types?

    No, not ALL methods, only the ones that really are asynchronous. There is for example no need to invoke a synchronous method asynchronously as it does nothing for the scalability anyway. Please refer to the following link for more information: http://blogs.msdn.com/b/pfxteam/archive/2012/03/24/10287244.aspx

    Also note that you can still generate asynchronous client proxies even it the service methods are implemented synchronously. Please refer to the following page for more information: http://www.dotnetcurry.com/showarticle.aspx?ID=983

    Please also remember to mark helpful posts as answer/helpful.

     

     

     

    Tuesday, October 21, 2014 3:25 PM
  • Thanks Magnus,

    Yes I saw that blog post. It seemed primarily related to shared library code which clearly should not put asynchronous wrappers on sync code. I wasn't totally clear how it applied to top level WCF services.

    I don't know what goes on under the hood of the WCF runtime. It seemed reasonable to suppose that thread scheduling would be enhanced if methods - even synchronous ones - immediately returned Task objects. (Not the case with Asp.net).

    I get confused by the current usage of the term asynchronous. I take asynchronous code mean methods decorated with the async modifier. Anything else that returns Task is parallel code. I thought maybe the 4.5 WCF runtime could achieve better parallelization when a service had to handle big bursts of hits on a simple method like my example.

    I also thought that ServiceContracts should be as stable as possible. Were it efficient to do so, returning a Task provides some degree of future proofing of any changes to the contained logic.

    cheers


    Dick Page

    • Proposed as answer by Mankdng Nef Friday, November 7, 2014 11:34 AM
    Tuesday, October 21, 2014 4:33 PM