I got a great question from an attendee at the Williston, Vermont, stop on the Northeast Roadshow yesterday regarding the behavior of a REST Starter Kit service that  I was demonstrating.  My demo is pretty simple: I hard code a collection right in the OnGetItems() method that the Starter Kit generates for you when you create a WCF REST Collection Service.   As part of the method, I had included code to reset the list each time the "GET" method ran, and I had done that a while ago without really thinking through why.

Well, in some ways it makes a lot of sense.  In REST, your URL (which in this case is represented by a WCF endpoint) represents a resource, and that resource should be the same for everyone.  As a result, the default settings for the service exposed by the REST Starter Kit have both the InstanceContextMode and ConcurrencyMode service behaviors set to Single.  So, the result is a singleton, single-threaded service representing the resource.   In my implementation a second retrieval of the resource will cause the list on the same instance to be repopulated, which of course leads to an exception if the list already contains the items.

So while that definitely explains the behavior, it brings up two important points as to how an 'out-of-the-box' service created with the REST Starter Kit may impact the scalability of your application.

  • The service is a singleton; therefore, one instance is servicing ALL of the client requests, and
  • That service is single-threaded, so only one thread can access the service at a time.

As a result, the WCF service has to serialize the requests across all of the clients.  Granted you can change this service behavior by modifying the attributes on the service, but by doing so you assume the responsibility for

  • keeping multiple instances in sync so every client 'sees' the same resource (if you change InstanceContextMode), and/or
  • providing thread-safe code in your implementation (if you change ConcurrencyMode)