We have developed a multithreaded server that recieves data from multiple client and calls different WCF services. There are many cases that two (or more) different clients call the server at the same and the server tries to call the remote WCF from two different threads simultaneously. We have encountered some issues, especially when the remote WCF service is down. Are we doing things correctly? is there a best practice for this scenario?
A:
You need to be a little more specific about the types of issues you are encountering, but you might want to read up on idempotency and stateful services.
Codebrain
2010-04-14 15:27:05
+2
A:
The best practice for most cases is this:
- your client calls a WCF service with a "per-call" pattern
- each request from a client gets its own, pristine server class instance that handles the request and gets disposed after it's done
- the server class is therefore single-threaded, non-reentrant, and doesn't have to deal with any multitasking issues
- the server class is stateless and doesn't hold on to any server resources or anything
- any "state" or data that needs to be persisted between calls is stored in a suitable location, e.g. a database
This is by far the easiest setup and should be the best choice for at least 80% of your cases.
Check out this excellent MSDN Magazine article Discover Mighty Instance Management Techniques For Developing WCF Apps by Juwal Lovy for more background on the various options you have.
marc_s
2010-04-14 15:28:09
Said it much more concisely than I could. I'll add that the service attribute for this scenario is `InsanceContextMode.PerCall`. If you are using a singleton or a reentrant service you could encounter all sorts of issues.
roufamatic
2010-04-14 15:46:55