Should you always disconnect from a WCF service between calls?

Question

I am using a WCF service to administer a windows service running on a remote machine. We have an administration client we use for modifying the windows service configuration, as well as monitoring the state of the service in real-time. For the real-time monitoring, we poll the service for it's state every second.

Currently, we are leaving the client connected all the time while monitoring the service but I continually read that it is recommended to connect and disconnect for each call, much like you would for a database.

Would it be recommended in our situation where we are making frequent calls to the service, or would connecting and disconnecting add too much overhead to the process?

Thanks

Answer 1

By default and as a recommended best practice, you're using the per-call activation in WCF, e.g. each request to your WCF service gets a new instance of a service class, that instance handles your request, returns a result, and then is disposed.

In this case, I don't really see any point in constantly breaking and re-establishing the communication channel (e.g. constantly disposing and re-creating the proxy client). There's nothing on the WCF service side that "lingers around" in memory and takes up resources or anything like that. Also, contrary to most databases, there's usually no "per-connection" licensing or anything involved, either.

What you need to be able to deal with in this scenario would be a situation where your communication channel goes into "faulted state", e.g. when something bad happens - when the service call fails and throws an exception, or when a network fluke causes your channel to break. In such a case, you need to have recovery mechanisms on your client side to handle this and re-establish the connection again.

The situation might be a bit different if you have session-oriented WCF services - but those should definitely be the exception, and only used when needed by all means.